PLAN DE CONTINGENCIA

Luis Dante Flores Nina

PLAN DE
Seguridad informtica
Mgr. Katty Rojas Len
CONTINGENCIA
2017-1
PLAN DE CONTINGENCIA
PLAN DE CONTINGENCIA
 PLAN DE CONTINGENCIA

INTRODUCCION

El sector empresarial uno de los pilares esenciales de la sociedad representa una gran
demanda ya que siempre esta implicado a numerosos accidentes tanto como naturales
o no naturales. Adema s, diariamente entabla contacto directo con la poblacio n. Por
medios de comunicacio n.

La industria estrate gica, permite que cuente con servicios ba sicos indispensables para
operar como nacio n, a trave s de servicios de telecomunicaciones, transporte y
energe ticos entre otros
 PLAN DE CONTINGENCIA

Qu es un plan de contingencia

Un plan de contingencia es un conjunto de procedimientos alternativos a la

operatividad normal de cada institucio n.

Su finalidad es la de permitir el funcionamiento de esta, aun cuando alguna de sus

funciones deje de hacerlo por culpa de algu n incidente tanto interno como ajeno a la
organizacio n.

Todas las instituciones deberan contar con un plan de contingencia actualizado,

valiosa herramienta en general basada en un ana lisis de riesgo.

Permitira ejecutar un conjunto de normas, procedimientos y acciones ba sicas de

respuesta que se debera tomar para afrontar de manera oportuna, adecuada y
efectiva, ante la eventualidad de incidentes, accidentes y/o estados de emergencias
que pudieran ocurrir tanto en las instalaciones como fuera de ella, por ejemplo el
secuestro de un funcionario.

Los riesgos los puedes eliminar, transferir, mitigar o aceptar. Ello dependera de varios
factores tales como la probabilidad de ocurrencia o impacto del riesgo.

OBJETIVOS

Los objetivos del plan de contingencia son el de planificar y describir la capacidad

para respuestas ra pidas, requerida para el control de emergencias. Paralelo al plan se
debe identificar los distintos tipos de riesgos que potencialmente podran ocurrir e
incorporar una estrategia de respuesta para cada uno, con algunos objetivos
especficos

Establecer un procedimiento formal y por escrito que indique las acciones a

seguir frente a determinados riesgos.

Optimizar el uso de recursos humanos y materiales

Un control adecuado para cumplir con las normas y procedimientos

 PLAN DE CONTINGENCIA

establecidos.

Los planes de contingencia son necesarios en todo sistema y no podra dejarse de lado
en el tema de seguridad.

ETAPAS DE UN PLAN DE CONTINGENCIA

Haciendo una sntesis para su elaboracio n la podramos dividir en cinco etapas.

1.- Evaluacin
2.- Planificacin
3.- Pruebas de viabilidad
4.- Ejecucin
5.- Recuperacin

El ciclo del plan de contingencia

El plan de contingencias sigue el conocido ciclo de vida iterativo PDCA (plan-do-check-

act, es decir, planificar-hacer-comprobar-actuar). Nace de un ana lisis de riesgo donde,
entre muchas amenazas, se identifican aquellas que afectan a la continuidad del
negocio.
Sobre dicha base se seleccionan las contramedidas ma s adecuadas entre diferentes
alternativas, siendo plasmadas en el plan de contingencias junto con los recursos
necesarios para ponerlo en marcha.
El plan debe ser revisado perio dicamente. Generalmente, la revisio n sera
consecuencia de un nuevo ana lisis de riesgo. En cualquier caso, el plan de
contingencias siempre es cuestionado cuando se materializa una amenaza, actuando
de la siguiente manera:

Si la amenaza estaba prevista y las contramedidas fueron eficaces: se corrigen

solamente aspectos menores del plan para mejorar la eficiencia.

Si la amenaza estaba prevista pero las contramedidas fueron ineficaces: debe

analizarse la causa del fallo y proponer nuevas contramedidas.

Si la amenaza no estaba prevista: debe promoverse un nuevo ana lisis de

riesgos. Es posible que las contramedidas adoptadas fueran eficaces para una
amenaza no prevista. No obstante, esto no es excusa para evitar el ana lisis de lo
ocurrido en un equipo.
 PLAN DE CONTINGENCIA

El plan de contingencias comprende tres subplanes. Cada plan determina las

contramedidas necesarias en cada momento del tiempo respecto a la materializacio n
de cualquier amenaza:

El plan de respaldo. Contempla las contramedidas preventivas antes de que

se materialice una amenaza. Su finalidad es evitar dicha materializacio n.

El plan de emergencia. Contempla las contramedidas necesarias durante la

materializacio n de una amenaza, o inmediatamente despue s. Su finalidad
es paliar los efectos adversos de la amenaza.

El plan de recuperacin. Contempla las medidas necesarias despus de

materializada y controlada la amenaza. Su finalidad es restaurar el estado de las
cosas tal y como se encontraban antes de la materializacio n de la amenaza.
Por otra parte, el plan de contingencias no debe limitarse a estas medidas
organizativas. Tambie n debe expresar claramente:

Que recursos materiales son necesarios.

Que personas esta n implicadas en el cumplimiento del plan.

Cua les son las responsabilidades concretas de esas personas y su rol dentro del
plan.

Que protocolos de actuacio n deben seguir y co mo son.

ELEMENTOS

Estrategias para el control de infecciones en el lugar de trabajo.

Mecanismos para la reduccio n del contagio entre trabajadores.

Estrategias de capacitacio n para el personal.

Sistemas de contingencia para asegurar el funcionamiento de la empresa

durante la emergencia.

Establecimiento de alianzas con otros miembros del sector para asistencia y

apoyo durante la pandemia.

METODOLOGA PARA EL PLAN DE CONTINGENCIA

 PLAN DE CONTINGENCIA

El disen ar e implementar un plan de contingencia para recuperacio n de desastres no

es una tarea fa cil; puede implicar esfuerzos y gastos considerables, sobre todo si se
esta partiendo de cero. Una solucio n comprende las siguientes actividades:
1. Debe ser disen ada y elaborada de acuerdo con las necesidades de la empresa.

2. Puede requerir la construccio n o adaptacio n de un sitio para los equipos

computacionales.

3. Requerira del desarrollo y prueba de muchos procedimientos nuevos, y e stos

deben ser compatibles con las operaciones existentes. Se hara participar a personal
de muchos departamentos diferentes, el cual debe trabajar en conjunto cuando se
desarrolle e implemente la solucio n.

4. Implicara un compromiso entre costo, velocidad de recuperacio n, medida de la

recuperacio n y alcance de los desastres cubiertos. .

Como con cualquier proyecto de disen o, un me todo estructurado ayuda a asegurar de

que se toman en cuenta todos estos factores y de que se les trata adecuadamente.
A continuacio n se muestran las principales actividades requeridas para
la planificacio n e implementacio n de una capacidad de recuperacio n de desastres.
1. Identificacio n de riesgos

2. Evaluacio n de riesgos

3. Asignacio n de prioridades a las aplicaciones

4. Establecimiento de los requerimientos de recuperacio n

5. Elaboracio n de la documentacio n

6. Verificacio n e implementacio n del plan

7. Distribucio n y mantenimiento del plan

Identificacin de riesgos

La primera fase del plan de contingencia, el ana lisis de riesgos, nos situ a en el lugar de
un asesor de una compan a de seguros. En esta fase, la preocupacio n esta relacionada
con tres simples preguntas: que esta bajo riesgo?, que puede ir mal? y cua l es
la probabilidad de que suceda?
Qu est bajo riesgo?
La primera de estas preguntas, que esta bajo riesgo?, necesita incorporar todos los
componentes del sistema susceptibles de ser dan ados, dando lugar a la pe rdida de
conectividad, computadoras o datos. Un diagrama de la arquitectura de todos los
componentes del sistema facilitara la realizacio n de un inventario de los elementos
que pueden necesitar ser restituidos tras un desastre. No hay que olvidar que tambie n
 PLAN DE CONTINGENCIA

el software necesita ser reemplazado, y que todos los productos software relevantes
han de ser identificados. Esto incluye cosas como las utilidades del sistema
de archivos empleados para facilitar las operaciones de red.
Un inventario completo de una red muestra de manera clara la complejidad de e sta.
Cualquiera que realice inventarios de componentes para redes, comprende los
problemas en el seguimiento del hardware y software utilizado por los usuarios
finales. Afortunadamente, existen algunos productos disponibles, como los de las
compan as Seagate Software, McAfee y otros, que facilitan la construccio n de un
inventario de los sistemas.
Una omisio n en el inventario fa cilmente puede dar lugar a una recuperacio n fallida
tras un desastre. El sistema de aplicacio n puede no encontrarse preparado para su uso
si alguno de sus componentes no esta disponible; en tal caso, es aconsejable estar
constantemente a la expectativa de los nuevos elementos que pueden haberse
olvidado. Por ejemplo, una aplicacio n para acceso remoto no funcionara si los cables
no esta n disponibles para conectar los mo dem.
Uno de los aspectos menos agradables a tener en cuenta, y que a menudo se pasa por
alto, es que las personas esenciales se vean afectadas por el desastre y sea necesario
recurrir a otras para realizar sus labores. Una formacio n diversificada en los sistemas
dentro de la organizacio n pude ayudar a reducir el impacto de la indisponibilidad de
uno de los colaboradores. Al menos, los manuales de las aplicaciones ma s importantes
para la empresa deberan encontrarse disponibles en un sitio externo.
Qu puede ir mal?
Lo ma s difcil en el plan de contingencia es responder a la pregunta, que
posiblemente pueda ir mal? La respuesta a tal cuestio n vara desde lo evidente hasta
lo casi increble. La ley de Murphy nos proporciona una coleccio n de extran os e
inesperados desastres. Por ejemplo, las inundaciones son bastante frecuentes, pero
pocos podan haber predicho la inundacio n de un sistema de tu neles del metro en la
ciudad de Chicago, en 1992, provocada por la rotura de una tubera a raz de las obras
de reparacio n de un puente.
Las clases ma s obvias de desastres son los desastres naturales que conllevan
tormentas de todo tipo o los acontecimientos geolo gicos como terremotos o volcanes.
En cada localidad existe la posibilidad de tener mal tiempo. En los u ltimos an os se han
visto huracanes destrozar instalaciones a lo largo Florida, islas del Caribe y el Golfo
de Me xico. Los tornados y vientos de elevadas velocidades han destruido edificios
cada an o en el interior de los Estados Unidos y Canada .
Las inundaciones pueden acaecer en casi cualquier lugar donde el drenaje existente no
sea capaz de absorber el volumen de lluvia o fango. Relacionado con las inundaciones
se encuentra el perjuicio producido por el agua. Cada an o los incendios en los edificios
provocan importantes dan os a los sistemas informa ticos debido al agua, cuando los
sistemas automa ticos de irrigacio n (sprinklers) se activan para apagar el fuego.
Los propios incendios constituyen uno de los peores desastres posibles. El calor, el
humo y el agua que rodea a los incendios son tremendamente perjudiciales para los
sistemas informa ticos. Los dispositivos de almacenamiento se deterioran fa cilmente
debido a las altas temperaturas y el humo. La eliminacio n de los residuos to xicos tras
el incendio de una oficina puede llevar meses, incluso an os. En los Estados Unidos, la
 PLAN DE CONTINGENCIA

agencia de proteccio n ambiental (EPA), en ocasiones, ha tenido que cerrar edificios

despue s de un incendio debido a la alta concentracio n de toxinas encontradas en el
mismo. Esto implica que puede no ser posible disponer de lo sistemas y datos hasta
bastante tiempo despue s del incendio. Existen compan a especializadas en preparar
operaciones especficas de limpieza de instalaciones vctimas del incendio, que dara n
su aprobacio n para enviar especialistas con trajes protectores al edificio incendiado,
recuperar el equipo de procesamiento de datos e intentar restaurar la informacio n de
los discos.
Deben considerarse mecanismos alternativos de acceso a la red en el caso de que, por
alguna razo n, sea imposible acceder al edificio, incluso aunque el edificio puede estar
en pie y operacional. Ejemplos de sucesos que pueden impedir e acceso al interior del
edificio son los accidentes qumicos e industriales, as como los motines y disturbios
callejeros.
El fuego no tiene por que darse necesariamente en la propia instalacio n para que el
problema sea devastador. Un incendio destruyo la oficina central dc Ameritech, en
Hinsdale, Illinois, en mayo de 1988, dejando a numerosos clientes sin servicio
telefo nico durante meses mientras la compan a reparaba la edificacio n dan ada.
Obviamente, las comunicaciones que empleaban las lneas telefo nicas que haban sido
enrutadas a trave s de esta instalacio n, se vieron seriamente afectadas.
Desgraciadamente, los ataques terroristas y otros actos deliberados de destruccio n
cometidos por personas pueden devastar sistemas e instalaciones. Este incluye actos
violentos (por ejemplo, descargar armas sobre los equipos informa ticos). Menos
excitante, pero igual de perjudicial para la organizacio n, es la pe rdida de equipos
debido al robo. Existen tambie n ataques a los datos contra los que hay que estar
prevenidos, en los que la gente destruye intencionadamente datos mediante su
borrado o inutiliza ndolos. Los virus se encuentran en este campo.
Los errores humanos son una de las causas ma s probables de la pe rdida o deterioro de
los datos. Si un error de este tipo provoca la pe rdida de un sistema en la red, tiene el
mismo efecto que cualquier otro tipo de desastre, y como tal debe ser tratado.

Cul es la probabilidad de que suceda?

Si se tuviera una cantidad ilimitada de recursos y fuera posible protegerse contra

todas las calamidades, esta pregunta carecera de intere s. Sin embargo, no se dispone
de recursos infinitos; de hecho, los recursos son bastante escasos. Por lo tanto, se
deben seleccionar los tipos de desastres contra los que uno intentara protegerse.
Obviamente, estos preciados recursos se querra n gastar en aquellos desastres que
tengan la mayor probabilidad de afectar a la organizacio n.
Por ejemplo, se podra intentar proteger los sistemas de la improbable ocurrencia de
la cada sobre el edifico de un meteorito procedente del espacio exterior. Esto no sera
tan valioso como proteger los sistemas de las inundaciones.
Responder a la pregunta: cua l es la probabilidad de que suceda? tambie n requiere de
ciertas consideraciones presupuestarias. Ello puede ayudar a asumir distintos
escenarios de presupuesto para comprender cua les son los costos de compromiso
para diferentes niveles de proteccio n y preparacio n. Finalmente, se puede estar
 PLAN DE CONTINGENCIA

expuesto a ciertas amenazas cuya proteccio n no esta al alcance del presupuesto, pero,
al menos, se es consciente de su existencia y, por lo tanto, es posible mejorar el plan en
un futuro.
Evaluacin de riesgos
Es el proceso de determinar el costo para la organizacio n de sufrir un desastre que
afecte su actividad. Si una inundacio n impidiera la actividad comercial durante cinco
das, la compan a perdera cinco das de ventas, adema s del deterioro fsico de los
edificios e inventario. En el caso de los sistemas informa ticos, la preocupacio n
principal es comprender la cantidad de pe rdida financiera que puede provocar la
interrupcio n de los servicios, incluyendo los que se basan en las redes.
Por ejemplo, si la empresa se anuncia a trave s o realiza negocios en Internet, cua l es
el costo de tener el servidor web inhabilitado? Si la red a trave s de la cual se produce
la solicitud de pedidos esta cada, o si el sistema de control de inventario utiliza la red,
cua l es el impacto sobre la productividad de la empresa?
Los costos de un desastre pueden clasificarse en las siguientes categoras:
Costos reales de reemplazar el sistema informa tico

Costos por falta de produccio n.

Costos por negocio perdido

Costos de reputacio n.

El costo real de los equipos y el software es fa cil de calcular, y depende de si se dispone

de un buen inventario de todos los componentes de la red necesarios.
Los costos de produccio n pueden determinarse midiendo la produccio n generada
asociada a la red. La empresa tiene una correcta valoracio n de la cantidad de trabajo
realizado diariamente y su valor relativo. La pe rdida de produccio n, debida a la
interrupcio n de la red, puede ser calculados utilizando esta informacio n.
Los costos por negocio perdido son los ingresos perdidos por las organizaciones de
ventas y marketing cuando la red no esta disponible. Si el sistema de solicitud de
pedidos no funciona y la empresa so lo es capaz de procesar el 25% del volumen diario
habitual de ventas, entonces se ha perdido el 75% de ese volumen de ventas.
Los costos de reputacio n son ma s difciles de evaluar y, sin embargo, es conveniente
incluirlos en la evaluacio n. Estos costos se producen cuando los clientes pierden la
confianza en la empresa y se llevan su negocio a otro sitio. Los costos de reputacio n
crecen cuando los retardos en el servicio a los clientes son ma s prolongados o
frecuentes.

Asignacin de prioridades en las aplicaciones

Despue s de que acontezca un desastre y se inicie la recuperacio n de los sistemas, debe

conocerse que aplicaciones recuperar en primer lugar. No hay que perder el tiempo
restaurando los datos y sistemas equivocados cuando la actividad empresarial
necesita primero sus aplicaciones esenciales.
 PLAN DE CONTINGENCIA

Esto implica la necesidad de determinar por anticipado cua les son las aplicaciones
fundamentales del negocio. Si la empresa es como la mayora, se tendra n aplicaciones
"muy importantes" dependiendo de a quie n se le pregunte. El departamento de
recursos humanos afirmara que el sistema de no minas es el ma s importante, el
departamento de ventas dira que es su sistema de entrada de pedidos, el
departamento de produccio n insistira en su control de inventario y el departamento
de compras asignara el papel de ma s importante a su sistema de facturacio n.
Desgraciadamente, no todos estos sistemas pueden ser el ma s importante; por lo
tanto, es fundamental que la direccio n ayude a determinar el orden en que los
sistemas sera n recuperados.
Es de esperar que esta informacio n sea aceptada de buen grado por todos los jefes de
departamento. Independientemente de ello, el plan de contingencia debera incluir la
lista de los sistemas y su prioridad. Esta seccio n del plan debera ser firmada por la
direccio n para minimizar las desavenencias.
Una vez conocido lo que se va a restaurar, debera disponerse de todo lo necesario
para la disponibilidad de tales aplicaciones. Un sistema de aplicacio n en una red esta
compuesto por los sistemas servidores, donde las aplicaciones almacenan sus datos,
los sistemas de estaciones de trabajo que los procesan, las impresoras o fax empleados
para entrada/salida, la red que interconecta todo, y el software de las aplicaciones. Las
aplicaciones cliente/servidor o distribuidas an aden un nivel extra de complejidad al
requerir que distintas partes de la aplicacio n residan en ma quinas separadas.
Puede caerse en la tentacio n de construir una infraestructura superior a la necesaria
para la aplicaciones de mayor prioridad. Por ejemplo, si actualmente la red tiene 50
estaciones de trabajo, se puede comenzar a trabajar inmediatamente en la
reconstruccio n de las 50 estaciones de trabajo. Sin embargo, si las aplicaciones ma s
prioritarias so lo necesitan cinco estaciones de trabajo, se debera detener la
reconstruccio n de las estaciones de trabajo una vez alcanzado el nu mero de cinco y
concentrar los esfuerzos en lograr que la aplicacio n funcione. Es mucho mejor intentar
lograr que un sistema pequen o funcione, que no uno ma s grande, y de esta manera se
ahorrara gran cantidad de tiempo en el proceso. De hecho, cuando se esta asignando
las prioridades a las aplicaciones junto con la direccio n, tambie n es posible
beneficiarse de la determinacio n del nu mero mnimo de estaciones de trabajo
necesarias para tener el sistema accesible. El taman o de la red siempre puede
incrementarse a posteriori una vez el sistema este en funcionamiento.
Una de las ventajas del enfoque basado en el sistema de aplicaciones es la cantidad de
tiempo necesaria para recuperar una aplicacio n comparada con la cantidad de tiempo
requerida para restaurar un servidor en su totalidad. Si la aplicacio n tiene so lo 500
MB de datos y el servidor 4 GB, es obvio que se ahorra una gran cantidad de tiempo
recuperando u nicamente la aplicacio n.
Sin embargo este enfoque requiere un conocimiento algo ma s detallado sobre los
sistemas que actualmente se tienen. En primer lugar, es necesario saber do nde se
encuentra toda la informacio n que emplean las aplicaciones y que dependencias entre
sistemas de archivos pueden existir. Si existen archivos del sistema que contienen
informacio n sobre la aplicacio n, como es el caso de los archivos .ini de Windows, es
necesario asegurarse de que esos archivos tambie n se recuperan junto a la aplicacio n.
 PLAN DE CONTINGENCIA

En segundo lugar, es preciso conocer co mo funciona el sistema de copias de seguridad

para realizar este tipo de recuperacio n selectiva. Aunque esto no supone
necesariamente una dificultad, no obstante esta operacio n debera ser familiar.

Establecimiento de requisitos de recuperacin

La clave de esta fase del proceso de elaboracio n del plan de migracio n es definir un
periodo de tiempo aceptable y viable para lograr que la red este de nuevo activa. Tal y
como se ha planteado en la seccio n anterior, la preocupacio n ba sica debera ser
disponer de las aplicaciones ma s importantes en primer lugar. El personal directivo de
la organizacio n deseara saber cua ndo estara n sus aplicaciones funcionado para
planificar la actividades de la compan a.
Es muy importante concederse una cantidad de tiempo adecuada y no realizar
estimaciones poco realistas sobre las propias posibilidades. No es el deseo de nadie
tener a un monto n de gente alrededor esperando la finalizacio n de las operaciones de
recuperacio n; una distraccio n de este tipo probablemente perturbe las labores. El
te rmino para este tiempo es tiempo de recuperacio n objetivo o en ingle s TRO
(Recovery Time Objective). El TRO definido debe ser verificado para comprobar que es
realista y factible, no so lo por uno mismo, sino por el resto de la organizacio n, que
puede ser requerido para realizar el trabajo.
La direccio n de la empresa debera colaborar ntimamente con el personal
de administracio n de redes para determinar el TRO de las aplicaciones. Aplicaciones
diferentes tendra n TRO diferentes.
Es necesario asegurarse de que se dispone de tiempo para recuperar las cintas
localizadas en la instalacio n de almacenamiento exterior y para adquirir los sistemas
necesarios. Por cierto, debera conocerse por anticipado co mo realizar las o rdenes de
compra de los equipos cuando la empresa se encuentra en un estado de total
desorganizacio n.
Es posible que sea necesario actualizar el sistema de copias de seguridad para
satisfacer el TRO. Un sistema de cinta que recupera datos a 2 MB por segundo
realizara la labor mucho ma s ra pido que uno que lo ejecute a 500 KB por segundo. Hay
que ser precavido y no suponer que se pueden hacer muchas cosas al mismo tiempo;
uno se puede encontrar cometiendo desafortunados errores que frenan la labor si no
se presta atencio n al trabajo que se tiene entre manos.

Elaboracin de la documentacin

Crear un documento que mucha gente pueda tener como referencia es quiza s lo ma s
difcil del plan de contingencia. No hay que engan arse: implicara un esfuerzo
significativo para algunas personas, pero ayudara a aprender cosas sobre el sistema y
puede que algu n da salve la empresa.
Los recursos necesarios para escribir y mantener un plan de contingencia representan
ma s de lo que puede realizarse en ratos libres y despue s de horas de oficina. La
direccio n de la organizacio n debe apoyar la iniciativa para que sea un e xito. Uno de los
problemas del plan de contingencia en un entorno de comunicaciones es que
 PLAN DE CONTINGENCIA

la tecnologa de redes cambia tan ra pidamente que resulta difcil permanecer al da.
Esto incluye nuevos dispositivos, as como nuevos sistemas de aplicacio n que
introducen su propio nivel de complejidad en este campo. Como ejemplo, conside rese
la recuperacio n de un gran sistema de base de datos relacional Unix. Este tipo de
trabajo requiere un conocimiento mucho ma s complejo del que corresponde a la
instalacio n de la base de datos y del que un administrador de redes es probable que
tenga; generalmente es necesario un administrador de base de datos, para el que
tambie n la labor sera un desafo.
Dado el hecho de que la tecnologa de red evoluciona tan ra pidamente, debera
planificarse la actualizacio n del plan de contingencia perio dicamente, por ejemplo una
vez al an o. Aunque la redaccio n del plan inicial supondra una gran cantidad de trabajo,
una vez que se dispone del plan, las actualizaciones son relativamente fa ciles.

Contenido del plan de contingencia

El plan de contingencia debe intentar definir las cinco a reas siguientes:
1. Listas de notificacio n, nu meros de tele fono, mapas y direcciones

2. Prioridades, responsabilidades, relaciones y procedimientos

3. Informacio n sobre adquisiciones y compras

4. Diagramas de las instalaciones

5. Sistemas, configuraciones y copias de seguridad en cinta

Hay que cerciorarse de que se sabe a quie n notificar en primer lugar cua ndo ocurre un
desastre. Por ejemplo, si hay un incendio, llamar primero a los bomberos y luego al
director general. Pueden existir otras personas o organizaciones identificadas con
caractersticas o conocimientos especiales que puedan ayudar a minimizar el dan o. Si
no se dispone de nu meros de tele fono o direcciones actualizados, se puede pasar muy
mal contactando con las personas afectadas.
Mapas mostrando las ubicaciones del centro de operaciones temporal y la instalacio n
externa pueden ahorrar mucho tiempo. Tambie n puede ser u til mostrar itinerarios
alternativos de acceso para el caso de que las rutas principales no se encuentren
disponibles.
Cuando en primer lugar se comienza a reflexionar sobre co mo responder a un
desastre, hay que centrarse en las prioridades establecidas. El tiempo pasa; el
trabajo debe empezar por recuperar inmediatamente las aplicaciones de mayor
prioridad. Las personas deberan disponer de instrucciones y responsabilidades
precisas. La relacio n entre tareas debera hallarse documentada de manera que pueda
identificarse cualquier cuello de botella que pudiera surgir. Por u ltimo, deberan
incluirse, de manera detallada, las operaciones y tareas que muestren las labores de
instalacio n y recuperacio n necesarias, debiendo ser fa ciles de leer y seguir. Tambie n
habra que incluir aqu los nu meros de tele fono de las organizaciones de asistencia
que pudieran requerirse.
 PLAN DE CONTINGENCIA

Como se ha mencionado anteriormente, debe saberse co mo expedir una solicitud de

compra y obtener los equipos para el centro de operaciones temporal. Esto significa
proporcionar a los vendedores la direccio n y cualquier instruccio n necesaria para
el transporte. No hay que suponer que todos los vendedores del mundo van a
enterarse de la difcil situacio n y venir a nuestro rescate. Es aconsejable disponer de
copias de las facturas, recibos y dema s para mostrarlos como prueba de compra.
Tambie n viene bien tener a mano una lista de 1os nu meros de serie de los equipos
hardware. No hay que olvidar que, actualmente, gran parte de los productos para
el mercado de comunicaciones de LANs se vende a trave s de grandes sistemas
de distribucio n, y que los fabricantes y desarrolladores de software de los productos
utilizados puede que no tengan ni idea de quie n es su cliente. No espere recibir los
repuestos de manera gratuita; en su lugar, debera ser capaz de llegar a acuerdos
especiales de compra y provisio n para sustituir los bienes perdidos.
Los diagramas de red simplifican cu gran medida la labor de construir una red. Un
diagrama detallado de la red, necesaria para las primeras aplicaciones, facilita y agiliza
la reanudacio n de las actividades. La asignacio n de etiquetas a los cables y su
almacenamiento en un lugar reservado, probablemente no llevara mucho tiempo y
evitara muchas confusiones con posterioridad. La otra ventaja de un diagrama de
conexiones es la posibilidad de emplear contratistas para realizar las instalaciones.
Alguien experimentado en la instalacio n del cableado y otros dispositivos de red, y que
se dedica a ello, puede ser capaz de realizarlo mejor y ma s eficientemente que uno
mismo.
Es posible ahorrarse horas o incluso das en el proceso de recuperacio n si existe la
posibilidad de almacenar algunos sistemas de repuesto con la capacidad de gestionar
tareas diferentes. Planifquese instalar una configuracio n gene rica que, como mnimo,
permita ejecutar las aplicaciones de mayor prioridad sin problemas. Si se desconoce
los productos que la gente tiene en sus PC, un producto para inventario de LAN puede
ayudar en la recopilacio n de esta informacio n. Despue s de que la red alternativa se
encuentre funcionando, y se disponga de un momento de respiro, sera posible
restaurar los PC con sus configuraciones anteriores utilizando la informacio n de
configuracio n extrada de los informes de inventario.
Hay que asegurarse la disponibilidad de un sistema de copias de seguridad de cinta en
funcionamiento. Si es posible, debe mantenerse un sistema de reserva, incluyendo
adaptadores SCSI, cables y software de unidades de dispositivo, en un sitio alterno. No
es inusual encontrarse con que los vendedores locales no disponen de existencias de
los productos necesarios, obligando, por tanto, a esperar el envo de los repuestos
antes de poder empezar la recuperacio n de los datos. Si se sigue este consejo, no hay
que olvidar actualizar este sistema cuando se actualicen los sistemas de copias de
seguridad de produccio n; en caso contrario, uno se puede encontrar con formatos de
cinta o bases de datos incompatibles u otros problemas que impedira n la restauracio n
de la informacio n.

Verificacin e implementacin del plan

 PLAN DE CONTINGENCIA

Una vez redactado el plan, hay que probarlo. Hay que estar seguro de que el plan va a
funcionar. Para ello, se debe ser esce ptico sobre el propio trabajo, de manera que
pueda uno probarse a s mismo que funciona. Psicolo gicamente, esto no es fa cil
porque con toda probabilidad se ha invertido una gran cantidad de tiempo y energa
personal en este proceso, aunque lo mejor sera, si es posible, situarse de manera
imparcial ante la confiabilidad del plan. Por consiguiente, han de realizarse
las pruebas para encontrar problemas, no para verificar que el plan funciona. Si
existen errores en la informacio n, to mese nota de ellos y corrjase el plan.

Comprobacin del plan por partes

No se puede tumbar el sistema algu n da para ver si se es capaz de recuperarlo.
Existen muchas y mejores formas de verificar un plan de contingencia sin causar
mayores interrupciones en el trabajo de la organizacio n. Algunas de las cosas en las
que habitualmente no se piensa a la hora de comprobar pueden ahorrar mucho
tiempo posteriormente. Por ejemplo, llamar a los nu meros telefo nicos de los
colaboradores incluidos en la listas telefo nicas del plan para confirmar si son actuales;
llamar a los vendedores y comprobar si disponen de existencias de productos, ya que
puede que hayan modificado su poltica de inventario. Algu n da, viajar hasta la
instalacio n alterna para saber do nde esta y co mo reconocer el edificio.
Por supuesto, tambie n es necesario verificar los procedimientos que se empleara n
para recuperar los datos. Comprue bese el software para la realizacio n de las copias de
seguridad para confirmar si pueden recuperarse las aplicaciones de mayor prioridad
de la manera esperada. Esto debera hacerse en una red aislada para evitar problemas
con el servidor de licencias. Por ejemplo, si la idea es unificar dos servidores mediante
la recuperacio n completa de uno de ellos en el servidor de repuesto y a continuacio n
restaurar so lo los archivos de datos de usuario procedentes del otro, finalmente se
tendra dos servidores con la misma licencia de software de servidor en la red, lo que
podra dar lugar a la difusio n por toda la red de mensajes de aviso sobre la licencia.
Incluso aunque se utilice una nueva licencia de sistema operativo de red, todava
existen otros conflictos como nombres de servidores duplicados y cualquier otro
problema de duplicacio n que podra causar problemas en los sistemas de produccio n.
Una vez recuperada la informacio n, verifquese si el usuario puede acceder a ella. Esto
requiere de algunas estaciones de trabajo conectadas a la red para simular aute nticos
usuarios finales con cuentas en los servidos originales. En este punto, puede ser
necesario actualizar el plan para incluir informacio n sobre el establecimiento de
cuentas de usuario. Comprue bese cada una de las operaciones del plan
individualmente y examnese entonces si, como resultado, se tiene un sistema de red
en funcionamiento. No esta de ma s verificar el plan con otras personas de la
organizacio n que se encuentren tan familiarizadas con los productos o procedimientos
empleados.
Revsese cada da la parte del plan relacionada con las operaciones de copias de
seguridad verificando la finalizacio n correcta de las mismas. Adema s, supervise esto
asegura ndose de que algunas personas de la organizacio n saben realizar copias de
seguridad adecuadamente, y comprobar su finalizacio n.

Distribucin y mantenimiento del plan

 PLAN DE CONTINGENCIA

Por u ltimo, cuando se disponga de un plan definitiva ya verificado, es necesario

distribuirlo a las personas que necesitan tenerlo. Inte ntese controlar las versiones del
plan, de manera que no exista confusio n con mu ltiples versiones. As mismo, es
necesario asegurar la disponibilidad de copias extra del plan para su depo sito en la
instalacio n exterior a en cualquier otro lugar adema s del lugar de trabajo. Mante ngase
una lista de todas las personas y ubicaciones que tienen una copia del plan. Cuando se
actualice el plan, sustituya todas las copias y recoja las versiones previas.
El mantenimiento del plan es un proceso sencillo. Se comienza con una revisio n del
plan existente y se examina en su totalidad, realizando cambios a cualquier
informacio n que pueda haber variado. En ese instante, se debe volver a evaluar los
sistemas de aplicacio n y determinar cua les son los ma s importantes para la
organizacio n. Las modificaciones a esta parte del plan causara n modificaciones
consecutivas a los procedimientos de recuperacio n. Sin embargo, esto no debera
verse como un problema porque probablemente la seccio n de procedimientos tenga
que actualizarse de todas formas debido a otros cambios. Si se han realizado
modificaciones al sistema de copias de seguridad, hay que cerciorarse de incluir la
informacio n sobre el funcionamiento del nuevo o actualizado sistema.
Este proceso llevara tiempo, pero posee algunos valiosos beneficios que se percibira n
aunque nunca tengan que utilizarse. Ma s gente conocera la red. Esto proporcionara a
la organizacio n una base te cnica ma s amplia para mantener correctamente la red.
Tambie n facilitara el crecimiento de una perspectiva global sobre la red dentro del
nu cleo de administradores de sistemas de informacio n y puede ayudar a identificar las
futuras o actuales a reas conflictivas. Uno de los aspectos ma s difciles en cualquier
labor distribuida, como es la gestio n y administracio n de LAN, es dar a conocer la
situacio n actual. El mantenimiento y verificacio n de un plan de migracio n ayudara a
que se produzca dicha comunicacio n dentro de la organizacio n

Pasos para elaborar un plan de contingencia

PLANIFICACION

Diagnstico
Cada vez que nos encontremos en una actividad que requiere el disen o de una
propuesta de solucio n para un determinado problema, es necesario siempre la
revisio n exhaustiva de cada uno de los componentes que conforman nuestro sistema,
es por esta razo n siempre debemos de realizar una etapa de diagno stico para poder
 PLAN DE CONTINGENCIA

asegurar que las acciones de solucio n propuestas tengan un fundamento realista y no

tener que volver a rehacer toda propuesta.

Organizacin Estructural y Funcional.

En este aspecto se deben describir y analizar las Direcciones, Gerencias o
dependencias en las que se divide la empresa o institucio n haciendo referencia de las
funciones ma s importantes que desempen an cada una de ellas, priorizando tales
funciones en relacio n al sistema productivo de bienes o servicios que desarrollan.

Estas Entidades tienen Organigramas que se rigen por Manuales de Organizacio n y

Funciones.

Servicios y/o Bienes Producidos.

En este punto se hara referencia sobre los bienes y/o servicios que produce a empresa
o institucio n segu n el orden de importancia por la generacio n de beneficios. Si la
empresa produce ma s de un bien la prioridad sera determinada segu n el criterio de
los Directivos.

Adema s se debe elaborar un directorio de clientes priorizando de acuerdo a la

magnitud de los bienes o servicios que consumen. Tambie n se hara n un breve ana lisis
del mercado de consumo de los bienes y servicios producidos, identificando las zonas
o sectores de mayor consumo.

Servicios y Materiales Utilizados.

Con relacio n a los servicios utilizados se debe elaborar un directorio de empresas o
instituciones que abastecen de energa, comunicacio n, transporte, agua, salud y otros
servicios resaltando la importancia de ellos en el sistema de produccio n de la entidad
y verificando la seguridad de los servicios sin problemas de afectacio n por algu n tipo
de problema.

Tambie n debe hacerse un directorio de todas las entidades abastecedoras de materias

primas o insumos para la produccio n de informacio n.

Inventario de Recursos Informa ticos.

El inventario de recursos informa ticos se realizara por dependencias y en forma

clasificada:

Computadoras: 386, 486 y las Pentium, impresoras, scanners, etc.

Programas: De sistemas operativos, procesadores de textos, hojas de ca lculo, lenguajes

de programacio n, software de base.
 PLAN DE CONTINGENCIA

Aplicativos Informa ticos: Del sistema de Contabilidad, de Tra mite Documentario,

Planillas, Almace n, Ventas, Presupuesto, Personal.

Equipos Empotrados: De Industrias: Hornos y envasadoras. De Banca y Seguros,

Cajeros automa ticos y bo vedas. De Oficinas, Centrales telefo nicas.

Estos inventarios debera n hacerse a trave s de formularios sistema ticamente

elaborados.

El procesamiento de este inventario puede ser de dos tipos:

Proceso Automatizado.- Utilizando herramientas informa ticas de diferente

nivel, grado de detalle y costo, que pueden acelerar el tiempo de la toma del
inventario, procesamiento de datos y emisio n de resultados.

Proceso Manual.- Utilizando formatos de recopilacio n de informacio n. El

conocimiento del Inventario de estos recursos nos permitira hacer una
evaluacio n de los riesgos de la operatividad de los sistemas de informacio n.
Cada formato consta de dos partes:
Datos componentes: Donde se registran los datos ba sicos de ubicacio n,
identificacio n y caractersticas primarias, as como tambie n su importancia,
compatibilidad y adaptabilidad.
Ana lisis del proceso de adaptacio n del componente:
Incluye datos de costos, fecha de culminacio n, medios utilizados y medidas de
contingencia.

Planificacin
La fase de planificacio n es la etapa donde se define y prepara el esfuerzo de
planificacio n de contingencia/continuidad. Las actividades durante esta fase incluyen:

Definicio n explcita del alcance, indicando que es lo que se queda y lo que se elimina, y
efectuando un seguimiento de las ambigu edades. Una declaracio n tpica podra ser, La
continuidad de los negocios no cubre los planes de recuperacio n de desastres que ya
fueron emitidos.

Definicio n de las fases del plan de eventos (por ejemplo, los perodos preevento,
evento, y post-evento) y los aspectos sobresalientes de cada fase.
 PLAN DE CONTINGENCIA

Definicio n de una estrategia de planificacio n de la continuidad del negocio de

alto nivel.
Identificacio n y asignacio n de los grupos de trabajo iniciales; definicio n de los
roles y responsabilidades.
Definicio n de las partes ma s importantes de un cronograma maestro y su
patro n principal.
Identificacio n de las fuentes de financiamiento y beneficios del negocio;
revisio n del impacto sobre los negocios.
Duracio n del enfoque y comunicacio n de las metas y objetivos, incluyendo los
objetivos de la empresa.
Definicio n de estrategias para la integracio n, consolidacio n, rendicio n de
informes y arranque.
Definicio n de los te rminos clave (contingencia, continuidad de los negocios,
etc.)
Desarrollo de un plan de alto nivel, incluyendo los recursos asignados.
Obtencio n de la aprobacio n y respaldo de la empresa y del personal gerencial
de mayor jerarqua. Provisio n de las primeras estimaciones del esfuerzo.
El plan debe ser ejecutado independientemente de las operaciones y
procedimientos operativos normales.
Las pruebas para el plan sera n parte de (o mantenidas en conjuncio n con) los
ejercicios normalmente programados para la recuperacio n de desastres, las
pruebas especficas del plan de contingencia de los sistemas de informacio n y
la realizacio n de pruebas a nivel de todos los clientes.
No habra un plan de respaldo, y tampoco se dara una reversio n ni se podra
frenar el avance del plan de contingencia.
Si ocurre un desastre, una interrupcio n, o un desfase de gran magnitud en los
negocios de la empresa durante el perodo del calendario de eventos, se
pondra n en pra ctica los planes de continuidad de los negocios o de
contingencia.
Si la organizacio n ha puesto en moratoria los cambios al sistema, se deben
permitir las excepciones a dicha moratoria solamente para los cambios de tipo
regulador o para los problemas ma s importantes que afecten la produccio n o
las operaciones de la empresa, y solamente despue s de haber obtenido la
aprobacio n del nivel ejecutivo.

IDENTIFICACION DE RIESGOS

La Fase de Identificacio n de Riesgos, busca minimizar las fallas generadas por

cualquier caso en contra del normal desempen o de los sistemas de informacio n a
 PLAN DE CONTINGENCIA

partir del ana lisis de los proyectos en desarrollo, los cuales no van a ser
implementados a tiempo.

El objetivo principal de la Fase de Reduccio n de Riesgo, es el de realizar un ana lisis de

impacto econo mico y legal, determinar el efecto de fallas de los principales sistemas
de informacio n y produccio n de la institucio n o empresa.

Anlisis y Evaluacin de Riesgos

Es necesario reconocer y reducir de riesgos potenciales que afecten a los productos y
servicios; es por ello que se considera dentro de un Plan de Contingencia, como
primer paso la Reduccio n de Riesgos, para favorecer el cumplimiento de los objetivos
institucionales.

El ana lisis y evaluacio n de riesgos se desarrolla en 2 situaciones

1- Para entidades que desarrollan Planes de Contingencias su plan de

adaptacin y no tienen soluciones adecuadas.

Para aquellas entidades que esta n realizando Planes de Contingencia, el ana lisis y
evaluacio n de riesgos consta de:

Evaluar el impacto de los procesos crticos.

Valorar la certificacio n de los proveedores
Privilegiar proyectos, eliminando aquellos que resultan extempora neos.
Detectar deficiencias ante cambios en los sistemas afectados.
Guardar copias de informacio n empresarial mediante convenios de soporte.

2- Entidades que a la fecha no han tomado previsin.

Para aquellas entidades que no esta n realizando Planes de Contingencia, el ana lisis y
evaluacio n de riesgos consta de:

Realizacio n un diagno stico integral del Sistema de Informacio n.

Elaborar una lista de Servicios afectados evaluando su importancia, magnitud
del impacto, cuantificar con niveles A, B, C u otro.
Identificar todos los procesos de los servicios afectados.
Analizar so lo los procesos crticos de los servicios.

Identificar los Procesos Crticos

Al igual que las situaciones de falla, las alternativas pueden ser infinitas. Por ende, se
deben identificar muchas para ser capaces de seleccionar las mejores opciones de
 PLAN DE CONTINGENCIA

contingencia. Comience por los riesgos ya identificados como prioridades ma ximas

porque causaran el mayor impacto negativo en los servicios y en las funciones crticas
de su organizacio n.

Anlisis de las Operaciones Actuales

El ana lisis de operacio n del me todo actual de trabajo (es decir, co mo y en que orden su
organizacio n obtiene funciones comerciales) puede revelar las oportunidades para
reducir, eliminar o simplificar ciertas operaciones o procesos. Algunas funciones
probablemente pueden ser realizadas por terceros sin pe rdida de control.
Probablemente pueden reducirse algunas operaciones en te rminos de pasos e
interfaces que ellos requieren. Un almace n parcialmente automatizado puede requerir
24 acciones manuales separadas para llenar una orden grande. Si la organizacio n
puede cortar esto en 33 por ciento, a 16 acciones manuales, la eficiencia incrementada
puede liberar algunos recursos que pueden usarse en otra parte. Por supuesto, tales
acciones van de la mano con la capacitacio n. Desde el punto de vista de los sistemas de
informacio n, tales consideraciones pueden ser cruciales porque puede haber una
necesidad de revertir a las operaciones manuales y en ciertos casos sostener las
operaciones existentes.

Si consideramos que No existe producto y/o servicio sin un proceso. De la misma

manera, que no existe proceso sin un producto o servicio. Aunque no todos los
procesos generan un producto o servicio u til (creando valor agregado) para la
institucio n. Por lo que es necesario realizar un ana lisis de las operaciones y los
procesos que involucran.

Organizacio n. Cualquier grupo, empresa, corporacio n, planta, oficina de ventas, etc.

Funcio n. Un grupo dentro de la organizacio n funcional. Funciones caractersticas

seran ventas y mercadeo, contabilidad, ingeniera de desarrollo, compras y garanta
de calidad.

Proceso. Cualquier actividad o grupo de actividades que emplee un insumo, le agregue

valor a e ste y suministre un producto a un cliente externo o interno. Los procesos
utilizan los recursos de una organizacio n para suministrar resultados definitivos.

Proceso de produccio n. Cualquier proceso que entre en contacto fsico con el

hardware o software que se entrega a un cliente externo, hasta aquel punto en el cual
el producto se empaca (por ejemplo, fabricacio n de computadoras, preparacio n de
alimentos para el consumo masivo de los clientes, refinacio n de petro leo,
 PLAN DE CONTINGENCIA

transformacio n de hierro en acero). Esto no incluye los procesos de embarque y

distribucio n.

Proceso de la empresa. Todos los procesos de servicios y los que respaldan a los de
produccio n (por ejemplo, de pedidos, proceso de cambio en ingeniera, de planilla,
disen o del proceso de manufactura). Un proceso de la empresa consiste en un grupo
de tareas lo gicamente relacionadas que emplean los recursos de la organizacio n para
dar resultados definidos en apoyo de los objetivos de la organizacio n.

Al emplear estas definiciones, se puede observar que casi todo lo que hacemos es un
proceso y que los procesos de la empresa desempen an un papel importante en la
supervivencia econo mica de nuestras organizaciones.

En todas las organizaciones existen, literalmente, centenares de procesos que se

realizan diariamente. Ma s del 80% de e stos son repetitivos, cosas que hacemos una y
otra vez. Estos procesos repetitivos (a reas administrativas, manufactureras e
intermedias) pueden y deben controlarse, en gran parte, tal como se vigilan los de
manufactura. Se manejan muchos procesos de las instituciones y empresas que son
tan complejos como el proceso de manufactura.

Uso de la Tcnica de Anlisis de Procesos

Consideremos para el uso de la te cnica de ana lisis de procesos:

El ciclo de vida empieza con la descripcio n de un proceso basado en las metas

del proyecto, mientras se utilizan los recursos descritos del proceso.
El proceso se fija al asignar los recursos.
El proceso puede instalarse en una ma quina o pueden ser procedimientos a
seguir por un grupo de personas.
El proceso es supervisado y medido durante su uso.

Los datos obtenidos de esta medida se evalu an durante todo el tiempo que se
desenvuelva el proceso. Una descripcio n del proceso existente puede empezar con un
informe actual, obtenido de la supervisio n y documentacio n del proceso.

El Proceso de Direccio n del Ciclo de Vida en la Figura muestra la descripcio n de los

componentes del proceso y la produccio n de los principales insumos de trabajo. La
descripcio n del proceso funcionalmente se descompone en e l:

1. Ana lisis del Proceso

2. Plan del Proceso

3. Aplicacio n del Proceso.

 PLAN DE CONTINGENCIA

El Ana lisis del proceso involucra identificacio n, mientras se analiza el proceso, y los
requisitos del proceso. El Plan del proceso involucra el modela miento de la
arquitectura y la descomposicio n funcional del proceso. La Aplicacio n del proceso
involucra llevar a cabo el plan del proceso para crear tareas a realizarse y
proporcionar la capacitacio n necesaria para las personas que realicen dichas tareas.
Tambie n la aplicacio n del proceso involucra la preparacio n del proceso para su
actuacio n en la empresa o institucio n, el proceso consiste en los detalles especficos
del proyecto y fijar los recursos necesarios.

Diagrama del Proceso Descompuesto

A continuacio n presentamos una lista de procesos tpicos de las empresas definidos
por IBM. Esto ayudara a definir los procesos de la empresa.

Manejo de ndices.
Disen o de sistemas de control.
Desarrollo de comunicaciones avanzadas
Disen o de componentes de cable
Prueba de disen o
Revisio n de disen o y materiales
Revisio n de documentos
Especificacio n de disen o a alto nivel
Coordinacio n entre divisiones
Disen o lo gico y verificacio n
Calificacio n de componentes
Disen o del sistema de energa
Divulgacio n del producto
Confiabilidad y utilidad del sistema
Requerimiento del sistema
Disen o interactivo de sistemas para el usuario
Ana lisis de la competencia
Apoyo de los sistemas de disen o
Desarrollo de la informacio n
Instrumentos de disen o fsico
Disen o de sistemas
Gerencia de cambio en ingeniera

Es el procedimiento por el cual se estudian los procesos dentro de una secuencia

(Lnea de produccio n) de produccio n o provisio n de servicios, que a continuacio n son
presentados, teniendo en consideracio n:

Las Funciones Institucionales.

Los procesos derivados.
Los subprocesos.
 PLAN DE CONTINGENCIA

IDENTIFICACIN DE SOLUCIONES

Un proyecto de plan de contingencia no sirve si se queda en plan o papel. Un plan de

contingencias debe contemplar todos los procesos institucionales sean estos manuales
y/o automatizados, evaluando el volumen de informacio n o materiales afectados, a fin
de definir la complejidad de los sistemas.

La magnitud, de un plan de contingencia sera proporcional a la complejidad,

importancia, costo del servicio al cual esta destinado a proteger y el riesgo asociado a
la misma. El esquema general del plan de contingencias de los sistemas de
informacio n, esta constituido por 3 grandes fases:

1. Fase de Reduccio n de Riesgos

2. Fase de Recuperacio n de Contingencia

3. Fase de Organizacio n de un Sistema de Alerta contra Fallas

Se debe tener en cuenta al determinar los objetivos, en que para metros generales se va
a basar, para poner en operacio n el plan de contingencias.

En cualquier caso, sus planes deben identificar dependencias e impactos y, al mismo

tiempo, los recursos necesarios para implementar cada alternativa de contingencia. Se
deben buscar alternativas creativas, que logren el efecto de mitigar el impacto en
caso de una falla. En la siguiente tabla se muestra la matriz del plan de contingencia y
algunos ejemplos.

Planificacin

La fase de planificacio n es la etapa donde se define y prepara el esfuerzo de

planificacio n de contingencia/continuidad. Las actividades durante esta faseincluyen:
 PLAN DE CONTINGENCIA

Definicio n explcita del alcance, indicando que es lo que se queda y lo que se

elimina, y efectuando un seguimiento de las ambigu edades. Una declaracio n
tpica podra ser, La continuidad de los negocios no cubre los planes de
recuperacio n de desastres que ya fueron emitidos.
Definicio n de las fases del plan de eventos (por ejemplo, los perodos pre-
evento, evento, y post-evento) y los aspectos sobresalientes de cada fase.
Definicio n de una estrategia de planificacio n de la continuidad del negocio de
alto nivel.
Identificacio n y asignacio n de los grupos de trabajo iniciales; definicio n de los
roles y responsabilidades.
Definicio n de las partes ma s importantes de un cronograma maestro y su
patro n principal.
Identificacio n de las fuentes de financiamiento y beneficios del negocio;
revisio n del impacto sobre los negocios.
Duracio n del enfoque y comunicacio n de las metas y objetivos, incluyendo los
objetivos de la empresa.
Definicio n de estrategias para la integracio n, consolidacio n, rendicio n de
informes y arranque.
Definicio n de los te rminos clave (contingencia, continuidad de los negocios,
etc.)
Desarrollo de un plan de alto nivel, incluyendo los recursos asignados.
Obtencio n de la aprobacio n y respaldo de la empresa y del personal gerencial
de mayor jerarqua. Provisio n de las primeras estimaciones del esfuerzo.
El plan debe ser ejecutado independientemente de las operaciones y
procedimientos operativos normales.
Las pruebas para el plan sera n parte de (o mantenidas en conjuncio n con) los
ejercicios normalmente programados para la recuperacio n de desastres, las
pruebas especficas del plan de contingencia de los sistemas de informacio n y
la realizacio n de pruebas a nivel de todos los clientes.
No habra un plan de respaldo, y tampoco se dara una reversio n ni se podra
frenar el avance del plan de contingencia.
Si ocurre un desastre, una interrupcio n, o un desfase de gran magnitud en los
negocios de la empresa durante el perodo del calendario de eventos, se
pondra n en pra ctica los planes de continuidad de los negocios o de
contingencia.
Si la organizacio n ha puesto en moratoria los cambios al sistema, se deben
permitir las excepciones a dicha moratoria solamente para los cambios de tipo
regulador o para los problemas ma s importantes que afecten la produccio n o
las operaciones de la empresa, y solamente despue s de haber obtenido la
aprobacio n del nivel ejecutivo.
 PLAN DE CONTINGENCIA

ELEMENTOS PARA CONSIDERAR EL PLAN

Aspectos que podran impactar

Indisponibilidad de personal indispensable durante periodos prolongados.
Restricciones de viaje y cierre de fronteras.
Pe rdida de proveedores clave y empresas asociadas por periodos prolongados.
Personal Estrate gico
Sus datos (Tele fono, Fax,E-mail, Direccio n) sean correctos y este n actualizados.
Se establezcan equipos de trabajo con el fin de cubrir periodos con elevado
ausentismo, favoreciendo la multidisciplinar edad.
Los empleados conozcan su responsabilidad como elementos crticos y
fundamentales

Asegurar que los procesos crticos pueden ser mantenidos duranteperiodos con altos
niveles de ausentismo.

ESTRATEGIAS

Preparar planes de contingencia para poder enfrentar la pe rdida de servicios

de terceros.
Informar a cliente y empresas asociadaspara fijar niveles de expectativas
deservicio.
Fuerza de Tarea
Desarrolla y difunde los lineamientos de planeacio n.
Promueve actividades de planeacio n de Recursos Humanos,
Comunicacio n, Aspectos Legales, Tecnologa, etc.
Apoya el desarrollo y aprueba los planes de Contingencia de las a reas.
Recomienda y aprueba decisiones estrate gicas.
Integra el plan de contingencia institucional / empresarial.
Monitorea e informa el progreso de las acciones de planeacio n.
Hace el seguimiento de metas.
Revisa la creacio n de una reserva estrate gica de insumos.

EQUIPO DE PLANEACIN

Apoya a la Fuerza de Tarea en aspectos de planeacio n de Recursos

Humanos.
Desarrolla planes especficos y polticas para entender las implicaciones de
Recursos Humanos
Informa el avance de la planeacio n a los empleados.

EQUIPO DE PROTECCIN CIVIL

 PLAN DE CONTINGENCIA

Apoya a la Fuerza de Tarea en aspectos de Proteccio n Civil.

Planea ejercicios de entrenamiento y capacitacio n
Para el personal.
Apoya a las a reas en el desarrollo de sus planes.
Coordina la ejecucio n de los ejercicios y los evalu a.

Anexos

CRITERIOS SOBRE SISTEMAS DE INFORMACION EN INTERNET

La seguridad es uno de los aspectos ma s conflictivos del uso de las tecnologas dela
informacio n. Es suficiente comprobar co mo la falta de una poltica de seguridad global
esta frenando el desarrollo de Internet en a reas tan interesantes y prometedoras,
como el comercio electro nico o la interaccio n con las administraciones pu blicas.Los
recientes avances en las telecomunicaciones y en la computacio n en red han
proporcionado la aparicio n de canales ra pidos para la propagacio n de datos a trave s
de sistemas digitales. Las redes abiertas esta n siendo utilizadas cada vez ma s como
una plataforma para la comunicacio n en nuestra sociedad, pues permiten ra pidos y
eficientes intercambios de informacio n con un bajo coste econo mico asociado y con
una fa cil accesibilidad. El desarrollo actual y las perspectivas de futuro de las
"superautopistas de datos" y de una infraestructura global de informacio n, es decir, de
Internet y de la World WideWeb (WWW), crean toda una variedad de nuevas
posibilidades. Sin embargo, la realizacio n efectiva de tales posibilidades esta n
influidas por las inseguridades tpicas delas redes abiertas: los mensajes pueden ser
interceptados y manipulados, la validez delos documentos se puede negar, o los datos
personales pueden ser recolectados deforma ilcita. Como resultado, el atractivo y
ventajas ofrecidas por la comunicacio n electro nica, tanto en el desarrollo de
oportunidades comerciales entre organizaciones privadas como en las interrelaciones
entre las organizaciones pu blicas y los ciudadanos, no pueden ser explotadas en su
totalidad.

CONCLUSION

Dependiendo del taman o de la institucio n u organizacio n se tendra que realizar

paralelamente un plan de contingencia por cada mo dulo del sistema de
Informacio n.
 PLAN DE CONTINGENCIA

Adicionalmente al plan de contingencias se debe desarrollar pruebas para

verificarla efectividad de las acciones en caso de la ocurrencia de los problemas
y tener la seguridad de que se cuenta con un me todo seguro.

No existe un plan u nico para todas las organizaciones, esto depende mucho de
la capacidad de la infraestructura fsica como de las funciones que realiza en
CPD(Centro de Procesamiento de Datos) mas conocido como Centro de
Co mputo