TIC-GCN-0001-Guia Para Elaboracion de Planes de Continui

Caja Costarricense de Seguro Social

Dirección de Tecnologías de Información y Comunicaciones

Administración de la Continuidad de la Gestión

Manual para Elaborar un Plan de Continuidad de la Gestión en

Tecnologías de Información y Comunicaciones TIC-ASC-CGN-0001

Noviembre 2007

Manual para Elaborar un Plan de Continuidad de la Gestión en TIC TIC-ASC-CGN-0001 Continuidad de la Gestión en Tecnología de Información y Comunicaciones Versión 1.0

Subárea Continuidad de la Gestión CCSS 2007 2 de 84

Tabla de Contenidos

ALCANCES ....................................................................................................................................... 5

ACTUALIZACIÓN ................................................................................................................................ 5

APROBACIÓN DEL DOCUMENTO........................................................................................................... 5

1. HISTORIAL DE REVISIONES ............................ ........................................................................... 6

DEFINICIONES .................................................................................................................................. 7

2. INTRODUCCIÓN ........................................................................................................................... 8

3. BENEFICIOS DE CONTAR CON PLANES DE CONTINUIDAD EN T IC ........................................ 9

4. DIFICULTADES PARA IMPLANTAR UN PLAN DE CONTINUIDAD EN TIC............................... 10

5. ETAPAS MÍNIMAS PARA ELABORAR UN PCTIC .............. ....................................................... 10

ANÁLISIS DE RIESGOS ..................................................................................................................... 10

DESARROLLO DE ESTRATEGIAS DE RECUPERACIÓN DE LAS OPERACIONES ........................................... 11

DESARROLLAR E IMPLEMENTAR EL PLAN DE CONTINUIDAD EN TIC ....................................................... 11

PROCEDIMIENTOS DE RECUPERACIÓN............................................................................................... 12

DESARROLLAR PROGRAMAS DE ENTRENAMIENTO Y CONCIENTIZACIÓN .................................................. 12

PRUEBAS Y DAR MANTENIMIENTO AL PLAN ......................................................................................... 12

PROCEDIMIENTO DE MEJORA CONTINUA ........................................................................................... 13

6. EL PLAN DE CONTINUIDAD EN TIC...................... .................................................................... 13

RELACIONES DE COORDINACIÓN ....................................................................................................... 14

GUÍA GENERAL PARA ELABORACIÓN DEL PLAN DE CONTINUIDAD EN TIC ............................................... 15

COORDINADOR DEL PLAN ................................................................................................................ 16

ORGANIZACIÓN Y ADMINISTRACIÓN PARA EL PLAN DE CONTINUIDAD TIC............................................... 16 Líder de Equipo ................................................................................................................16

Suplente del Líder de Equipo............................................................................................17

Miembros de equipo .........................................................................................................17

Composición de equipos para la continuidad ....................................................................17

Posición y habilidades requeridas del personal .................................................................19

Centro de Operaciones de Emergencia (COE)..................................................................19

DISTRIBUCIÓN DEL PLAN DE CONTINUIDAD DEL TIC............................................................................ 20

DIRECTRIZ DE CAPACITACIÓN EN PLANES DE CONTINUIDAD .................................................................. 20

DIRECTRIZ DE MANTENIMIENTO DE LOS PLANES DE CONTINUIDAD......................................................... 21

RESPONSABILIDADES ...................................................................................................................... 21

TIEMPOS MÁXIMOS DE INTERRUPCIÓN. .............................................................................................. 21

7. ACTIVACIÓN DEL PLAN DE CONTINUIDAD DE TIC.......... ....................................................... 21

ACTIVACIÓN DEL PLAN..................................................................................................................... 21

NOTIFICACIÓN INICIAL...................................................................................................................... 21



PRIMERA NOTIFICACIÓN DE ALERTA................................................................................................... 22

VERIFICACIÓN DEL DESASTRE .......................................................................................................... 23

ACTIVACIÓN DEL EQUIPO DE RECUPERACIÓN...................................................................................... 23

SITIO ALTERNO DE RESPALDO DE DATOS............................................................................................ 23

ESCALAMIENTO DE NOTIFICACIONES ................................................................................................. 24

EVALUACIÓN DE DAÑOS................................................................................................................... 24

ESTABLECER EL COE ..................................................................................................................... 25

NOTIFICACIÓN A LOS MIEMBROS DEL EAE.......................................................................................... 26

SESIÓN INFORMATIVA ...................................................................................................................... 26

8. RECOMENDACIONES DE RECUPERACIÓN.................... ......................................................... 27

ELABORAR LAS RECOMENDACIONES DE RECUPERACIÓN ..................................................................... 27

9. SEGUIMIENTO DEL EVENTO..................................................................................................... 27

10. ANEXO I – PLANTILLA PARA CONTROL DEL DESARROLLO DE LAS FASES ...................... 28

11. ANEXO II – GUÍA PARA LA ELABORACIÓN DE ANALISIS DE RIESGOS ............................... 29

INTRODUCCIÓN ............................................................................................................................... 29

DESARROLLO DE ANÁLISIS DE RIESGOS (DEFINICIONES) ..................................................................... 30

EL ANÁLISIS DE RIESGOS (CATEGORÍAS DE RIESGOS).......................................................................... 30

METODOLOGÍA ............................................................................................................................... 32

CAPTURA DE LA INFORMACIÓN DE RIESGOS........................................................................................ 32

ANÁLISIS DE PROBABILIDAD, IMPACTO Y RIESGO ................................................................................. 33

DESARROLLO DE ESTRATEGIAS DE RIESGOS ...................................................................................... 36

DESARROLLO DE ESTRATEGIAS DE RIESGOS- ARV002 ....................................................................... 37

12. ANEXO III – GUÍA PARA ELABORAR PLANES DE CONTINUIDA D DE LA GESTION EN TIC . 38

INTRODUCCIÓN ............................................................................................................................... 38

13. HISTORIAL DE REVISIONES ............................ ......................................................................... 41

14. PLAN DE CONTINUIDAD................................ ............................................................................ 42

INFORMACIÓN DE LA UNIDAD (PTC001, PTC002).............................................................................. 42

INVENTARIO DE HARDWARE Y SOFTWARE - PTC003........................................................................... 43

ANÁLISIS DE RIESGOS ..................................................................................................................... 44

TIEMPOS MÁXIMOS DE INTERRUPCIÓN (PTC004)............................................................................... 46

ORGANIZACIÓN PARA LA CONTINUIDAD (PTC005).............................................................................. 47

COMPOSICIÓN DE EQUIPOS (PTC006) .............................................................................................. 48

INFORMACIÓN DE CONTACTOS EXTERNOS (PTC007) .......................................................................... 49

UBICACIÓN DEL CENTRO DE OPERACIONES DE EMERGENCIA (PTC008) ............................................... 50

SITIO ALTERNO DE RESPALDO DE DATOS (PTC009) .......................................................................... 51

MATRIZ DE ENSAYOS DEL PLAN (PTC010) ......................................................................................... 52

PROCEDIMIENTOS DE RECUPERACIÓN (HARDWARE)(PTC011) ............................................................ 53



PROCEDIMIENTOS DE RECUPERACIÓN (SISTEMA DE INFORMACIÓN O APLICACIÓN)(PTC012) ................. 57

PROCEDIMIENTOS DE RECUPERACIÓN (EQUIPO O LÍNEA DE COMUNICACIÓN. (PTC013) ......................... 60

RESUMEN DEL ESTADO DEL EVENTO (PTC014)................................................................................. 62

EVALUAR EL ESTADO DEL EQUIPO DE TIC (PTC015) ......................................................................... 64

15. ANEXO IV – GUÍA PARA EL DESARROLLO DE ENSAYOS DEL P LAN DE CONTINUIDAD EN TIC 65

INTRODUCCIÓN ............................................................................................................................... 65

ENSAYOS DEL PLAN......................................................................................................................... 65

DIRECTRIZ PARA EJECUCIÓN DE LOS ENSAYOS DEL PLAN .................................................................... 66

OBJETIVOS DE LOS ENSAYOS ........................................................................................................... 66

COORDINADOR DE LOS ENSAYOS ...................................................................................................... 67

RESPONSABILIDADES DEL CPC EN LOS ENSAYOS ............................................................................... 67

TIPOS DE ENSAYOS ......................................................................................................................... 67

FRECUENCIA DE LOS ENSAYOS ......................................................................................................... 68

CALENDARIO DE ENSAYOS ............................................................................................................... 68

EVALUACIÓN DE LOS ENSAYOS ......................................................................................................... 69

GUÍA PARA EL DESARROLLO DE ENSAYOS .......................................................................................... 70

MATRIZ DE ENSAYO DEL PLAN (PTC016)........................................................................................... 71

ENSAYO DEL PLAN (PTC017) .......................................................................................................... 72

16. ANEXO V – MANTENIMIENTO DEL PLAN (PTC018).......... ....................................................... 73

17. ANEXO VI – DOCUMENTO PROCEDIMIENTOS ALTERNOS DE TRA BAJO............................. 74

INTRODUCCIÓN. .............................................................................................................................. 74

EVALUACIÓN DE FACTIBILIDAD PARA LA DOCUMENTACIÓN .................................................................... 74

DESCRIPCIÓN DEL FORMULARIO PARA DOCUMENTACIÓN DE PAT ......................................................... 75

PROCEDIMIENTO ALTERNO DE TRABAJO ENCUESTA............................................................................. 78

PROCEDIMIENTO ALTERNO DE TRABAJO (PTC019) ............................................................................. 80

EJEMPLO. PROCEDIMIENTO ALTERNO DE TRABAJO.............................................................................. 81

18. ANEXO VII – ESCALACION DE EVENTOS (PTC020) ......... ....................................................... 82

19. ANEXO VIII – PLAN DE CAPACITACION (PTC021)......... .......................................................... 83

CALENDARIO CAPACITACIÓN - PTC021............................................................................................. 83

20. ANEXO IXX – PRESUPUESTO DE EQUIPO PARA CONTINGENCIA S...................................... 84

PRESUPUESTO DE EQUIPO PARA CONTINGENCIAS (PTC022) .............................................................. 84

21. ANEXO XX - ABREVIATURAS ............................ ....................................................................... 84



Alcances Este manual describe las guías mínimas que deben cumplirse para la elaboración de un plan de continuidad de la gestión en Tecnologías de Información y Telecomunicaciones. Estas consideraciones son obligatorias para todas las unidades regionales y centrales en Tecnologías de Información y Telecomunicaciones, de la Caja Costarricense del Seguro Social.

Actualización Por las consideraciones de las guías incluidas, periódicamente se revisarán para actualizar, eliminar o agregar nuevas disposiciones o normas, acorde a la evolución de las tecnologías de información y comunicaciones en la Institución.

Aprobación del documento El documento fue acogido en acuerdo del Comité Gerencial de Tecnologías de Información, que en su sesión N.21 celebrada el lunes 09 de julio del 2007 y aprobado en firme en la sesión N.23 del 30 de octubre 2007.



1. Historial de revisiones

Fecha Versión Descripción Autor

Marzo 2006 0.1 Versión inicial Lic. Leonardo Fernández M

Lic. Laura Morales Ureña

Septiembre 2006 0.2 Actualización del documento Lic. Leonardo Fernández M

Kpmg. S.A.

Abril 2007 0.3 Revisión documento Lic. Laura Morales

Octubre 2007 1.0 Aprobación del documento

Sesión N.23 del 20 de octubre 2007

Comité Gerencial Tecnlogias de Informacion

Noviembre 2007 1.0 Actualización documento

Registro aprobación

Lic. Leonardo Fernandez M

Pricewaterhouse S.A.



Definiciones Planeamiento de Continuidad del Negocio (Business C ontinuity Planning - BCP)

Es el proceso de desarrollar planes y procedimientos dentro de la organización con el propósito de responder ante un desastre o interrupción significativa del negocio, de forma tal que las operaciones críticas del negocio puedan continuar sus operaciones dentro de un límite aceptable de tiempo, de acuerdo a lo establecido por la gerencia general.

Planeamiento de Recuperación ante Desastres (Disast er Recovery Planning - DRP)

Planes, actividades y programas diseñados para permitir a la organización retornar a una condición aceptable, luego de un desastre o interrupción significativa del negocio.

A diferencia del concepto anterior, el DRP está orientado a la recuperación de los servicios y de TI y consecuentemente contiene los detalles de recuperación requeridos por el equipo de soporte para restaurar la plataforma tecnológica.

Para efectos de este documento y los esfuerzos desarrollados en la CCSS, se seguirá denominando Plan de Continuidad para Tecnología de Información y Comunicaciones (PCTIC).

Tiempos máximos de interrupción (TMI) Lapso de tiempo (horas hábiles) en el cual el proceso y los servicios de TI deben ser restaurados a un nivel operacional aceptable.



2. Introducción

La criticidad de la información dentro de la organización y la complejidad de los sistemas de información hacen que las organizaciones sean más sensibles ante las amenazas de la integridad de la información. Los incidentes de perdida de información que con cierta frecuencia se presentan y son dados a conocer por los medios de comunicación, provocan alarma en las Organizaciones ya que afectan a la totalidad de las actividades de las mismas. Sin embargo, incidentes menos relevantes como el fallo de una línea de comunicación puede tener un efecto devastador en los procesos de la organización.

En la actualidad la regulación de la mayoría de los sectores no suele hacer una referencia específica a la continuidad de negocio. En general, los administradores suelen poner énfasis en la integridad y disponibilidad de la información más que en la disponibilidad de los sistemas como base a la continuidad del negocio de la empresa.

Ante esta realidad la Dirección de Tecnologías de Información y Comunicaciones ha visto la necesidad de buscar soluciones que obedezcan a estrategias que aseguren la seguridad y continuidad de sus procesos operativos sustantivos.

Un aspecto a considerar dentro de este entorno, es el Riesgo o Amenaza, factor que no puede ser pasado por alto, debido a que se encuentra inmerso en cualquier operación organizacional en donde intervienen Procesos, Gente y Tecnología. Por tanto, aquellas soluciones orientadas a la mitigación y/o manejo de estos riesgos, cobran vital importancia para nuestra Institución.

Las consecuencias que la Institución puede enfrentar, cuando uno o varios de sus procesos sustantivos están inoperantes o son incapaces de brindar un servicio son muchos, y en algunos casos pueden llegar a ser catastróficos representando un costo muy alto para la Institución. Algunas de esas causas son descritas a continuación: � Desastres naturales � Problemas técnicos � Problemas organizacionales (huelgas, leyes aceptadas por el congreso, regulaciones

gubernamentales, leyes internacionales ) � Problemas de terceros involucrados en la producción o soporte a un servicio � Problemas con los proveedores de insumos o subproductos � Fallas en equipos o maquinaria especializada � Servicios de soporte a producción o servicio � Errores humanos, etc.

Estudios realizados sobre este asunto, revelan cómo cualquier negocio termina rápidamente siendo incapaz de realizar o ejecutar las actividades del día a día, cuando los sistemas, aplicaciones y componentes de tecnología de información no están disponibles a causa de un siniestro, eventualidad o contingencia.

Adicionalmente estos contratiempos pueden deteriorar la imagen de la Institución e inciden en la satisfacción de nuestros usuarios.

Por lo anterior la Caja Costarricense del Seguro Social requiere ir más allá y ejecutar un alcance más amplio que no solo contemple la continuidad en TIC, sino que también incluya la continuidad operativa de las operaciones, lo anterior da origen a los conceptos sobre la Continuidad del Negocio y Administración del Riesgo (conceptos descritos por las mejores prácticas para la Administración de Servicios de Tecnologías de Información sugeridas por ITIL y sustenta y justifica la generación de un Plan de Continuidad en TIC.



El enfoque principal de un Plan de Continuidad en TIC considera recuperar las operaciones de los procesos sustantivos de una organización, dentro de un espacio de tiempo determinado, buscando equilibrar el costo y viabilidad de éste. Cabe mencionar que la generación de un Plan de Continuidad en TIC, tiene una relación muy estrecha con la alta gerencia de la organización, ya que el éxito de este tipo de prácticas organizacionales depende en gran medida, del grado de involucramiento de estos actores. 3. Beneficios de contar con Planes de Continuidad e n TIC Es fundamental ver los beneficios que trae a la Institución la elaboración de Planes de Plan de Continuidad en TIC, a partir de los elementos siguientes:

� Protección de la viabilidad de la gestión al enfrentar una interrupción mayor, mediante una estrategia de continuidad.

� Aprovechamiento de la infraestructura actual para ese objetivo.

� Aprovechamiento de la documentación actual (procesos y procedimientos).

� Equilibrio entre las variables: costo, beneficio y riesgo.

� Definición de una estructura organizacional para el Plan de Continuidad de la Gestión en TIC.

� Diseño de medidas para reducción de riesgos identificados.

� Definir una estrategia global de continuidad de negocio, basada en la recuperación de la operación y servicios sustantivos de cualquier organización.

� Selección de componentes para cumplir con la estrategia de continuidad.

� Creación de una cultura de continuidad de negocio.

� Tener la documentación necesaria y suficiente para alguna auditoria.

� Institucionalización del BCP.

� Contar con planes de continuidad de negocio, los cuales podrán ayudar a la organización a operar sus procesos más críticos de negocio durante un periodo contingente.

� Contar con análisis de riesgo e impacto de los componentes (activos) que soportan al proceso.

� Identificar los puntos más críticos y vulnerables de los procesos de negocio de la organización.

� Identificar áreas de oportunidad dentro de la organización, como resultado de los análisis y alternativas de operación durante un periodo contingente.

� Cálculos sobre el costo aproximado de pérdida, al no poder ejecutar un proceso crítico.



4. Dificultades para implantar un Plan de Continuid ad en TIC Algunas dificultades se podrían presentar al tratar de llevar a cabo un proyecto orientado a la implantación de un Plan de Plan de Continuidad en TIC, entre las que se puede citar las siguientes:

� Falta de Compromiso de la Dirección.

� Los programas particulares no se integran entre sí.

� En el diseño del plan no se realiza una gestión correcta del riesgo.

� No se realizan simulacros o planes de prueba completos.

� Limitaciones de presupuesto.

� Falta de involucramiento del personal de la organización. 5. Etapas mínimas para elaborar un PCTIC

Un proyecto típico de BCP como mínimo incluye los componentes siguientes:

� Análisis de Riesgos. (Análisis de Impacto en el Negocio).

� Desarrollo de Estrategias de Recuperación de las Operaciones.

� Desarrollar e implementar el Plan de Continuidad en TIC.

� Desarrollar programas de entrenamiento y concientización.

� Pruebas y mantenimiento al BCP.

� Procedimientos de mejora continua.

Análisis de Riesgos

Busca determinar los eventos y situaciones externas que pueden afectar adversamente a la organización y su infraestructura, tanto por una interrupción como por un desastre, evalúa el daño que dichos eventos pueden causar, y los controles requeridos para prevenir o minimizar los efectos de pérdida potencial. Provee un análisis costo-beneficio para justificar la inversión requerida para mitigar los riesgos identificados.

Esta etapa está orientada a:

� Entender las pérdidas potenciales.

� Determinar la exposición de la Organización a pérdidas potenciales.

� Identificar controles para prevenir o mitigar los efectos de pérdidas potenciales.

� Evaluar, seleccionar y utilizar apropiadamente herramientas y metodologías para análisis de riesgos.

� Evaluar la efectividad de los controles.

� Evaluar y controlar los riesgos.

� Administrar los registros vitales para el negocio.



Para el desarrollo del Análisis de Riesgos refiérase al documento “Guía para la elaboración del Análisis de Riesgos Anexo II, como insumo para el Plan de Continuidad de la Gestión en TIC.

Los resultados del Análisis de Riesgos serán utilizados como insumo para el desarrollo de la estrategia de TI, identificando oportunidades de mejora que ayuden a disminuir la proclividad del negocio a interrupciones. Debe entenderse que los riesgos identificados en este análisis, únicamente deberán ser considerados para preparar una estrategia de mitigación de riesgos previo a cualquier interrupción o desastre. No serán utilizados para estrategias o acciones durante o después de un evento que provoque la interrupción de los servicios.

Dentro del análisis de riesgos hay que desarrollar un análisis del impacto del negocio:

El Análisis de Impacto en el Negocio (BIA), dado que algunos de sus propósitos principales son determinar la urgencia por la recuperación de las funciones del negocio e identificar los recursos necesarios para iniciar y mantener la operación del negocio en un lugar alterno, deberá ser llevado a cabo por todas las áreas críticas del negocio.

Dicho análisis deberá identificar claramente lo siguiente:

� Información general de las áreas funcionales.

� Información de los niveles de impacto (cualitativo, cuantitativo, regulatorio).

� Información de las funciones críticas para la supervivencia del área.

� Los requerimientos de recursos para el área (instalaciones, tecnología, servicios de soporte, recursos humanos).

La actualización de este análisis deberá actualizarse al menos una vez al año o cuando las condiciones en el negocio así lo obliguen.

Desarrollo de Estrategias de Recuperación de las Op eraciones

En esta etapa se deberán establecer diversas estrategias orientadas a la recuperación de la plataforma tecnológica de acuerdo con los objetivos de tiempo de recuperación establecidos por el negocio.

Como parte de la etapa se deberá realizar lo siguiente:

� Identificar los requerimientos estratégicos para la recuperación de la plataforma de TI.

� Valorar la oportunidad de estrategias alternativas contra los resultados del Análisis del Impacto del Negocio.

� Preparar un análisis costo/beneficio de las estrategias de recuperación.

� Seleccionar posibles sitios alternos de operación y respaldo de datos.

� Entender los requerimientos contractuales para los servicios del negocio.

Desarrollar e implementar el Plan de Continuidad en TIC

En esta etapa se debe diseñar, desarrollar e implementar el plan de continuidad que proveerá de la información necesaria para recuperar las operaciones de TI dentro del marco de tiempo establecido por el negocio. Para lograr este objetivo se deberá:

� Determinar los requerimientos del Plan.

� Determinar la estructura del Plan.



� Diseñar el Plan.

� Definir y documentar los procedimientos de recuperación (se aclaran más adelante).

� Desarrollar los requerimientos de documentos a utilizar durante y después del desastre.

� Implementar el Plan.

� Establecer pruebas y procedimientos de control, distribución, capacitación y mejora continua del Plan.

Procedimientos de Recuperación

Los procedimientos de recuperación son documentos que apoyarán el proceso de recuperación de la plataforma de TI posterior a la manifestación de cualquier evento que los afecte parcial o totalmente (escenario de peor caso). De esta forma deberá documentarse procedimientos para la recuperación de:

� Sistemas de información;

� Servidores;

� Equipos y líneas de comunicación. En todos los casos se deberá considerar con prioridad aquellos elementos (de los citados anteriormente) que sean críticos de acuerdo a los procesos críticos del negocio y considerando los tiempos máximos de interrupción identificados en cada uno de los casos. Los procedimientos de recuperación deberán incluir toda la información necesaria para la recuperación (“desde cero”) de cualquiera de los elementos de la plataforma crítica del negocio. Para ello se ha incluido en el plan de continuidad tres documentos, para: sistemas de información, servidores y equipos y líneas de comunicación. El responsable por su documentación es cada uno de los encargados de los equipos o sistemas. Para su preparación deberá considerarse siempre el “escenario de peor caso” de forma tal que se documente todo lo necesario para una recuperación total. Posteriormente y en caso de utilizar la documentación, según se haya dado una pérdida total o parcial, la información deberá utilizarse según sea necesario.

Desarrollar programas de entrenamiento y concientiz ación

En esta etapa, el objetivo principal será desarrollar un programa orientado a crear y mantener conciencia en el negocio, además de mejorar las habilidades requeridas para desarrollar e implementar los planes de recuperación. Para lograr esto deberá:

� Definir los objetivos de entrenamiento y concientización.

� Desarrollar y ejecutar programas variados de entrenamiento.

� Desarrollar programas de concientización.

� Identificar otras oportunidades de educación.

Pruebas y dar mantenimiento al Plan

Esta etapa se orienta a probar con antelación y coordinar ejercicios, documentando y evaluando los resultados de ellos. Desarrollar procesos para mantener vigentes las capacidades para lograr



una adecuada recuperación de las operaciones de TI, en acuerdo con la dirección estratégica del negocio.

Para el logro de los objetivos se deberá:

� Establecer y ejercitar el Plan.

� Determinar los requerimientos de ejercitación.

� Desarrollar escenarios realistas para las pruebas.

� Preparar reportes y procedimientos de control de los ejercicios.

� Ejecutar ejercicios.

� Obtener retroalimentación de los resultados de las pruebas e implementar las mejoras requeridas.

Procedimiento de Mejora Continua

Se deberá establecer en el procedimiento para administrar la mejora continua del plan de continuidad. Considere para esto los elementos siguientes:

� Administración del cambio en la organización. Los dueños de procesos o de la plataforma de TI son los responsables por reportar al coordinador del plan de continuidad o de los planes, los cambios que se den en el ambiente. Esto con el fin de que el administrador coordine los esfuerzos de actualización correspondientes.

Los cambios a considerar serán todos aquellos que modifiquen la estructura del plan de continuidad tales como cambios en el personal, cambios en los procesos de negocio, cambios de la plataforma de TI, etc.

� Capacitación del personal. Se deberá definir un plan de capacitación permanente al personal involucrado en los esfuerzos para asegurar la continuidad de TI. Los procesos de capacitación deberán ejecutarse al menos una vez al año, o cuando un cambio en el negocio así lo fuerce.

� Ensayo del plan. Definir un plan para ensayar periódicamente los planes de continuidad y recuperación. Esto deberá realizarse al menos una vez al año. En los ensayos deberá participar todo el personal involucrado en los esfuerzos de continuidad y recuperación. Los ensayos se podrán desarrollar gradualmente, de forma que durante el año se cubra la totalidad de la documentación. A partir de los ensayos se deberá documentar los resultados de los mismos y desarrollar procedimientos para la actualización inmediata de toda la documentación que se vea afectada.

� Revisión constante. El coordinador del plan de continuidad será el responsable por mantener una vigilancia constante sobre el negocio y sobre TI, para identificar eventuales cambios que fuercen a un proceso de actualización de los planes de continuidad y recuperación.

6. El Plan de Continuidad en TIC

Los Planes de Continuidad de TIC (PCTIC) han sido diseñados para proveer respuesta inmediata y una subsiguiente recuperación operacional de los procesos considerados como



críticos. Una interrupción puede ser ocasionada por situaciones diversas como son: problemas de procesamiento, comunicaciones, pérdida de acceso al edificio, fuego u otros. Sin embargo, el factor común en todas las situaciones es una interrupción en el acceso a los sistemas de información que residen en las computadoras principales (servidores) y que soportan las operaciones.

Esos procedimientos de recuperación constituyen una herramienta útil para hacer organizada y efectiva la ejecución de las tareas durante la recuperación de las operaciones de TI. Adicionalmente, funcionan como guías, prácticas y sencillas, que ayudan a la ejecución de las actividades y que las decisiones puedan ser realizadas por personal diferente de aquellos que están familiarizados con ellas, previendo que parte del personal podría no estar disponible en el momento del desastre.

En cualquiera de los casos, esos planes serán entregados al líder de equipo y él será responsable de darlos a conocer al resto del personal involucrados en el equipo de recuperación. Todo cambio en los procedimientos como consecuencia de la modificación de la forma de trabajo, recursos involucrados (técnicos y humanos), etc. deberá ser comunicado oportunamente al Coordinador del Plan de Continuidad (CPC) para proceder con la actualización y distribución del plan.

En el documento Guía para Elaborar Planes de Continuidad de TIC encontrará un modelo a seguir para los procedimientos de recuperación, los cuales deberán definirse para: � Servidores; � Sistemas de información y aplicaciones; y, � Equipos de comunicación.

Este Plan ha sido diseñado únicamente para enfrentar situaciones de desastre que afecten al área de Tecnología de Información y Comunicaciones, particularmente sus computadoras principales.

Relaciones de coordinación

Las relaciones de coordinación son aquellas que se establecen con diferentes centros ya sean internos o externos, con el fin que en caso de presentarse algún evento o suceso donde nuestras operaciones queden fuera de servicio, estos centros nos ayuden a salir de la crisis y podamos iniciar las operaciones en los tiempos establecidos. Relaciones de coordinación internas:

- Dirección de Tecnologías de Información y Comunicaciones - Área de Seguridad y Calidad Informática. - Sub – Área de Continuidad de la Gestión - Dirección Regional (la que corresponda). - Otros centros Regionales.

Relaciones de coordinación externas:

- Bomberos. - Compañía Nacional de Fuerza y Luz - Cruz Roja. - Instituto Costarricense de Electricidad - Empresas Locales de suministros de electricidad



- Hospitales Nacionales

Guía general para elaboración del Plan de Continuid ad en TIC

Como guía general se muestra en esta sección los pasos a seguir para la elaboración del Plan de Continuidad de TIC. Para mayor referencia, deberá tener consigo la “Guía para Elaborar Planes de Continuidad en TIC” Anexo III, en donde encontrará los instrumentos a utilizar y que se referencian en este documento.

1. Para iniciar con el Plan deberá documentar la Carátula y el formulario control de Revisiones y aprobaciones (PTC000).

2. Prepare la información de la unidad (PTC001), información de persona a cargo de la crisis (PTC002), y disponer de un Inventario de hardware y software. Para este último se incluye en la guía un modelo de la información mínima que deberá contener dicho inventario (PTC003).

3. Desarrolle un análisis de riesgos y vulnerabilidades de la situación actual en la plataforma de TI. Para esto utilice la Guía de Elaboración de Análisis de Riesgos . Como resultado de dicho análisis deberá obtener la matriz de análisis de riesgos así como la tabla de riesgos completa (ARV001 y ARV002). En adelante, deberá dar seguimiento a las estrategias de mitigación de riesgos que fueron planteadas y realizar las actividades pertinentes para que dichas estrategias se cumplan.

4. Complete la tabla Tiempos Máximos de Interrupción incluida en el documento “Guía de Elaboración de Plan de Continuidad TIC”,(PTC004) priorizando la recuperación de los diferentes procesos de TIC así como de sus componentes de plataforma tecnológica. La priorización deberá realizarse con base en los requerimientos del negocio para la prestación de sus servicios.

Los tiempos máximos de interrupción se obtienen a partir de un análisis de impacto en el negocio en donde se identifican los procesos o funciones del negocio, su nivel de criticidad o bien qué tanto depende el negocio de esos procesos y qué tanto tiempo puede pasar antes que su interrupción se vuelva crítica.

Para la identificación de los TMI se deberá realizar un ejercicio con las áreas usuarias del negocio en donde los responsables de las funciones determinen con base en su conocimiento, cuánto será el tiempo que puede transcurrir antes que la interrupción de la función o servicio provoque daño o perjuicio al negocio. Para esto se puede utilizar escalas para posteriormente clasificar la prioridad y criticidad. Ejemplo: menos de cuatro horas, un día, dos días, cinco días, dos semanas, etc.

5. Documente en un Organigrama la Organización para la Continuidad (PTC005), estableciendo las relaciones de mando para la ejecución y control de las labores. En la Guía se muestra un ejemplo del tipo de organigrama que deberá documentar, para los equipos de recuperación y donde debería únicamente incluir los nombres de las personas que conformarían los equipos. Paralelamente deberá completar la información específica de las personas que conforman los equipos en la tabla de Composición de Equipos.

6. Complete la información de los formularios Información de contactos externos(PTC007), Ubicación del Centro de Operaciones de Emergencia (PTC008), Sitio Alterno de Respaldo de Datos (PTC009) y Matriz de Ensayos del Plan (PTC010).

7. Complete los Procedimientos de Recuperación tanto en hardware, software y comunicaciones, en que le permitirán recuperar la plataforma de TI ante diversos escenarios que podrían afectarlo sean objeto de una interrupción o de un desastre mayor. Los formularios muestra a seguir para desarrollar esta documentación se incluyen en el documento “Guía de Elaboración de Plan de Continuidad TIC”. Deberá completar un documento de recuperación (utilizando el correspondiente) para cada servidor, equipo de comunicación o aplicación miembro de la plataforma de TI.



8. Elabore una lista de abreviaturas propias de la plataforma tecnológica y definiciones de aspectos técnicos muy especializados.

9. Planee y ejecute ensayos de los documentos y de la organización del PCTIC. Pruebe principalmente de los Procedimientos de Recuperación.

10. Realice los ajustes correspondientes a la documentación según los resultados de los ensayos realizados.

11. Realice sesiones de capacitación con el personal involucrado para asegurar que todos tienen claro su rol en el momento de la contingencia y que todos entienden claramente la documentación y los procedimientos a seguir en caso de una contingencia.

12. Revise y someta a aprobación de acuerdo con la Política de Continuidad Institucional según los aprobadores asignados en el punto 1 de la presente guía los documentos desarrollados.

13. Distribuya copias del Plan según corresponda.

14. Planee el procedimiento de mejora continua (actualización y capacitación regular en el tema) a todo el personal involucrado, este procedimiento (mantenimiento y revisión del plan) debe ser al menos una vez cada seis meses. Para ello use el formulario PTC014.

Coordinador del Plan

El Coordinador del Plan de Continuidad, adelante el CPC, es responsable de la supervisión y coordinación de todas las actividades de recuperación establecidas en este plan. Conforme se implante el Plan, será el responsable de acumular y administrar toda la información que esté incluida en el mismo.

El CPC es responsable de obtener copias de este Plan y distribuirlas a los líderes de los equipos y a sus suplentes. Debe además encargarse de mantener copias de este Plan seguras en los sitios alternos que se mencionan.

Todas las actividades de este Plan deben ser ensayadas, tanto para asegurar que los procedimientos funcionarán correctamente, como para brindar entrenamiento a los diferentes equipos. El CPC programará los ensayos y documentará los resultados favorables o negativos. Cuando un ensayo falle, deberá trabajar junto con el líder del equipo correspondiente para resolver los problemas, actualizar el Plan y programar otro ensayo.

Organización y administración para el Plan de Conti nuidad TIC

Dentro de la administración, diseño, coordinación, ejecución y desarrollo de pruebas del plan de continuidad de TIC es necesario contar con varios equipos de trabajo, el cual depende del tamaño de la organización, de los recursos existentes, (recursos humanos, equipos electrónicos y procesos), por lo tanto esta guía esta diseñada para cualquier tamaño y complejidad de la unidades.

Líder de Equipo

En cada equipo de recuperación deber definirse un Líder, quien debe ser una persona con liderazgo natural, para un grupo particular, donde los demás esperan que dirija y tenga la capacidad para realizar decisiones durante el periodo de recuperación. Los líderes de los equipos de recuperación se asignan a cada uno de los procesos de negocios y deberán realizar, sin limitarse a, las tareas siguientes:



� Participar en las sesiones de trabajo programadas para la evaluación de los riesgos e impactos del proceso bajo su responsabilidad.

� Aportar su conocimiento del proceso de negocios en el análisis y diseño de los procedimientos de recuperación.

� Liderar la recuperación del proceso de negocios a su cargo en los simulacros y prácticas, y en las situaciones reales.

� Identificar e implantar mejoras al plan de contingencia y a los procedimientos de recuperación bajo su responsabilidad.

� Servir de enlace entre el equipo de recuperación y el equipo administrador. � Mantenimiento de la información del estado de recuperación � Coordinar con otros equipos de recuperación.

Los líderes de los equipos de recuperación y sus suplentes deben contar con el perfil siguiente: � Conocer profundamente el proceso de negocios bajo su responsabilidad. � Poseer conocimientos de análisis y diseño de procesos de recuperación. � Poseer un perfil psicológico que lo faculte para liderar grupos en catástrofes o bajo

situaciones de alta tensión emocional. � Tomador rápido y seguro de decisiones y hábil comunicador. � Dedicar el tiempo que se requiera para a atender y ejecutar eficiente y oportunamente las

labores que se le asignen en el proyecto.

Suplente del Líder de Equipo

El suplente sirve como Líder de Equipo si el líder de equipo designado esta imposibilitado o no disponible para administrar el equipo. Por lo tanto, debe disponer del mismo perfil que el líder y cumplir con las mismas funciones.

Miembros de equipo

Los miembros de equipo son responsables de ejecutar las acciones de recuperación. Debido a que las actividades son usualmente desarrolladas por múltiples personas, quienes pueden variar dependiendo de las circunstancias y recursos disponibles, es mejor evitar la identificación de tareas con individuos específicos. En su lugar, la planeación se limita a experiencias y requerimientos específicos, los cuales son necesarios para realizar tareas particulares.

Composición de equipos para la continuidad

En el caso particular del área de TI, y como parte de la organización se podrá definir los equipos siguientes:

a- Equipo de Tecnología de Información (EATI)

Una vez que la recuperación ha iniciado, el equipo EATI supervisa y coordina todas las actividades internas de recuperación, y monitorea el avance de las acciones realizadas por el personal de los equipos de Operaciones (EO), Comunicaciones (EC) y Aplicaciones (EA). Entre las principales responsabilidades del EATI están las siguientes:



� Analizar los reportes de daños.

� Reportar el estado de la recuperación y cualquier otro problema que surja.

� Notificar al personal del equipo de recuperación de TI.

� Servir como punto focal para todas las consultas planteadas por el personal de recuperación del área de Tecnología de Información.

� Habilitar el sitio alterno de tal forma que este listo para recuperar las aplicaciones.

El equipo EATI esta conformado por personal de áreas especializadas de la Dirección de Informática; por tal razón, una descripción de las funciones y responsabilidades de cada área se describen a continuación:

b- Equipo de Comunicaciones (EC)

Este equipo de trabajo se encarga de las acciones de recuperación de las comunicaciones y debe informar al líder del EATI de la interrupción en el servicio y el avance en la recuperación.

Algunas de sus responsabilidades son las siguientes:

� Desarrollar y documentar las configuraciones de las comunicaciones de datos.

� Determinar el daño en la red de comunicaciones y asegurar la provisión del equipo de reemplazo.

� Coordinar la instalación del software del sistema operativo que permita la restauración de las comunicaciones.

� Ordenar e instalar el hardware necesario para establecer comunicaciones con las oficinas.

� Coordinar con entes externos (ej. ICE, RACSA) para restaurar el servicio y ordenar las comunicaciones.

� Probar que las comunicaciones se hayan establecido adecuadamente.

c- Equipo de Operaciones (EO)

Este equipo de trabajo coordina con el Líder del EATI el avance de la restauración de las operaciones de las plataformas críticas. Entre sus responsabilidades están las siguientes:

� Asegurar la disponibilidad de los respaldos necesarios en la recuperación.

� Restaurar archivos y sistema operativo en el sitio de recuperación.

� Elaborar calendarios de operaciones en el sitio de recuperación.

� En caso necesario, coordinar actividades necesarias para restaurar las facilidades en el sitio principal o en la nueva ubicación.

� Ordenar e instalar el hardware necesario para el procesamiento normal en el sitio permanente.

d- Equipo de Aplicaciones (EA)

Este equipo coordina con el Líder del EATI y supervisa la restauración de las aplicaciones que residen en el computador principal. Entre sus responsabilidades están las siguientes:



� Coordinar la recuperación de las aplicaciones en el computador alterno y en el computador principal, en caso necesario.

� Reconstruir el ambiente de operación de las aplicaciones que residen en los servidores.

� Soportar el esfuerzo de los usuarios para actualizar los datos de la aplicación.

� En caso necesario, desarrollar un plan de trabajo detallado para moverse del sitio-alterno al sitio principal.

En la Guía se muestra un ejemplo del organigrama que deberá documentar, para reflejar la Organización para la Continuidad.

Posición y habilidades requeridas del personal

La cantidad de personal que se requiere para atender el plan de continuidad deberá ser definida en cada una de las localidades de la CCSS. En el cuadro siguiente se muestra un detalle de las posiciones con que se debería contar en cada ubicación y las habilidades mínimas específicas de cada rol.

Nombre Habilidades específicas

Coordinador del Plan de Continuidad de TI

� Conocimiento de la plataforma tecnológica

� Capacidad de trabajo en equipo y coordinación con los líderes de los equipos de recuperación

Líder equipo de recuperación de las comunicaciones

� Conocimiento técnico en la infraestructura de las comunicaciones � Capacidad de trabajo en equipo y coordinación con proveedores y

miembros de los equipos de recuperación

Líder equipo de recuperación de las operaciones

� Conocimiento de las diferentes plataformas tecnológicas

� Capacidad para liderar equipos de recuperación de las operaciones

Líder equipo de recuperación de los sistemas

� Conocimiento del portafolio de sistemas de la organización

� Capacidad para liderar equipos de recuperación de los sistemas

Miembros de los equipos de recuperación de TI

� Conocimiento técnico de la plataforma, de los sistemas, de las comunicaciones

Centro de Operaciones de Emergencia (COE)

El Centro de Operación de Emergencias (COE) es un local o área desde la cual se controla toda la emergencia y se realizan actividades de evaluación inicial, coordinación y toma de decisiones. Es el sitio que albergará al personal responsable de coordinar los esfuerzos de la recuperación.

El Coordinador del Plan de Continuidad (CPC) determinará cual localidad, de las disponibles, será utilizada en el momento del desastre. Para ello, deberá basarse en las condiciones específicas del incidente y las localidades afectadas. Entre otros, el CPC debe coordinar lo siguiente:

� Asegurar que el mobiliario adecuado, teléfonos, suministros de oficina y espacio han sido proporcionados para los miembros de los equipos Consejo Director y Administrador de Emergencias.



� Mantener un registro de todas las actividades realizadas en el COE, incluyendo el estado de la emergencia, asignación de personal, minutas de reuniones, etc.

� Coordinar el personal en el COE para asegurar que hay teléfonos disponibles para la atención de llamadas entrantes.

La documentación de la información referente al COE se hará en la plantilla “Ubicación del COE” que se incluye en la “Guía para Elaborar Planes de Continuidad de TIC”.

Distribución del Plan de Continuidad del TIC

Al menos dos copias completas del Plan de Continuidad de TI deben ser mantenidas fuera sitio (por ejemplo donde se almacenan respaldos fuera de sitio o en su defecto la casa del responsable CPC).

Directriz de distribución del plan.

El Plan de Continuidad de TI debe ser distribuido a todo el personal autorizado, ya que sólo el personal activo puede tener acceso al plan. Si un individuo deja de laborar para el negocio o una de sus unidades específicas, es su responsabilidad retornar las copias y todos los duplicados o partes duplicadas de este plan a su superior respectivo. A nadie fuera de la organización le será permitido a leer, revisar, copiar o auditar el Plan sin la autorización formal y escrita por parte del Coordinador del Plan de Continuidad.

Distribución de los documentos

Debido a la confidencialidad de este documento únicamente el Coordinador del Plan (CPC) y, mantendrá una copia completa del mismo. Subconjuntos del Plan serán distribuidos tomando como base la premisa “need-to-know” y de la manera siguiente:

Adicionalmente, es necesario desarrollar el mecanismo de control para asegurar que todas las copias de las hojas que han sido modificadas sean colocadas fuera de circulación. Para controlar la actualización de los documentos se recomiendan acciones como las siguientes:

� Enviar secciones completas para reemplazar aquellas con cambios, en lugar de enviar sólo las hojas que han cambiado.

� Asegurar que los líderes provean algún tipo de recibo para verificar que recibieron las nuevas versiones del plan. El retornar las hojas reemplazadas podría ser considerado como un recibo.

� Mantener el control de los planes de recuperación para propósitos de seguridad.

Directriz de capacitación en planes de continuidad

Debe ser política proveer la capacitación necesaria a los funcionarios, sobre el Plan de Continuidad de TIC, con el propósito de asegurar la obtención de una participación acorde con los lineamientos establecidos en este plan y esperados en el evento de un desastre.

La capacitación puede ser considerada como la mejor manera de proporcionar al personal con el conocimiento apropiado de sus responsabilidades ante un desastre. Adicionalmente ayuda a mantener el Plan actualizado al permitir la identificación de áreas de mejora y de actualización en el mismo.



Básicamente hay dos tipos de capacitación o entrenamiento: el inicial y el continuo. De esta manera, los miembros de los equipos de recuperación recibirán un entrenamiento inicial y sesiones posteriores y recurrentes de capacitación.

Directriz de Mantenimiento de los planes de continu idad

Los planes deben ser revisados por lo menos una vez cada seis meses.

Responsabilidades

Coordinador del Plan

Es responsabilidad del Coordinador del Plan de Continuidad (CPC) el establecer un programa de capacitación continua, que asegure que todo el personal requerido en un evento contingente esté en capacidad de activar y ejecutar el Plan.

Todo el personal

Es responsabilidad de todo el personal el comprender el papel que deberá desempeñar y las funciones que ha ejecutar en caso de desastre. Para lo cual y en el momento que se requiera deberá participar de las actividades de capacitación establecidas por el CPC.

Tiempos máximos de Interrupción.

Los tiempos máximos de interrupción se obtienen a partir de un análisis de impacto en el negocio en donde se identifican los procesos o funciones del negocio, su nivel de criticidad o bien qué tanto depende el negocio de esos procesos y qué tanto tiempo puede pasar antes que su interrupción se vuelva crítica.

Para la identificación de los TMI se deberá realizar un ejercicio con las áreas usuarias del negocio en donde los responsables de las funciones determinen con base en su conocimiento, cuánto será el tiempo que puede transcurrir antes que la interrupción de la función o servicio provoque daño o perjuicio al negocio. Para esto se puede utilizar escalas para posteriormente clasificar la prioridad y criticidad. Ejemplo: menos de cuatro horas, un día, dos días, cinco días, dos semanas, etc.

7. Activación del plan de continuidad de TIC

Activación del Plan

Se deberá establecer un protocolo de notificación oficial ante la ocurrencia de un desastre, además de establecer el nombre de la persona responsable por la activación de dicho protocolo. Una vez que la notificación se ha hecho, el responsable activará al personal apropiado para realizar las actividades de soporte y recuperación.

Notificación Inicial

Los procedimientos de activación del plan serán realizados después que los planes iniciales de evacuación y respuesta de emergencias han sido implantados. Estos procedimientos de activación del plan documentan la evaluación inicial, las decisiones y las actividades de



activación de equipo que serán realizadas. Se deberá proveer la coordinación y comunicación centralizada de todas las respuestas al incidente. Específicamente, estos procedimientos incluyen la activación del personal de soporte apropiado, asistencia en el desarrollo de las recomendaciones de recuperación y en la activación de los equipos de recuperación tanto de los procesos de negocio como de los de tecnología.

En caso

de... Ejemplo de notificación Inicial

Hacer lo siguiente...

Incidente en el edificio

Si la severidad del incidente lo requiere, el personal de seguridad notificará a la Administración del edificio, el cual realizará una evaluación inicial del incidente y determinará si otras notificaciones son necesarias. Si se considera necesario, el CPC debe ser notificado.

Interrupción de servicios

En el evento de una interrupción del servicio de los sistemas de información, una notificación inicial podría surgir directamente del personal de Tecnología de Información. En esta situación, la Dirección de Informática deberá realizar una evaluación inicial del incidente y determinará si notificaciones adicionales son requeridas. Si se considera necesario, el CPC debe ser notificado.

Primera notificación de alerta

La notificación de una evento contingente podría provenir de fuentes diversas, dependiendo de la naturaleza y momento de la emergencia. No obstante, la respuesta inicial a la notificación estará dictada por los procedimientos de emergencia de la organización y las prácticas estándares de operación.

A continuación una lista típica de acciones y flujos de notificación iniciales:

1. Si usted es el primero en tener conocimiento del incidente, realice todas las acciones de notificación de emergencia, de acuerdo con los procedimientos establecidos por la organización (por ejemplo, activar la alarma contra incendios).

2. Notifique al CPC y provea la información siguiente: 2.1. Su nombre 2.2. Una descripción del evento 2.3. Un reporte preliminar de daños 2.4. Información relacionada con cualquier intento de notificación a los contactos 2.5. Un número telefónico y lugar donde puede ser localizado

3. Si es notificado después de horas o vía un escalamiento del problema, considere la información siguiente: 3.1. Fecha y hora de la notificación 3.2. Persona realizando la notificación 3.3. Descripción de la situación 3.4. Cualquier instrucción especial.



Verificación del Desastre

Para la verificación del desastre deberá seguir las actividades siguientes:

1. Si el acceso a su área de trabajo está disponible, realice una inspección para evaluar el daño de los aspectos siguientes: 1.1. Equipo electrónico (Estado: destruido, fácil de recuperar, disponibilidad de uso). 1.2. Registros vitales: copias de archivos, manuales, documentación, etc. y datos en otros

medios (computadoras personales, microfilm, etc.). Esto ayuda en determinar un plan de restauración o salvamento de recursos.

1.3. Equipo de oficina, trabajo en proceso, formulario, misceláneos. Analice el estado de operación en el momento del desastre e identifique la pérdida de datos críticos. Evalúe el impacto en las operaciones si los datos deben ser restaurados desde respaldos.

2. Obtenga una evaluación de daños en relación con lo siguiente: 2.1. Tiempos de recuperación del equipo electrónico (computadoras personales, terminales

y equipo de comunicaciones) 2.2. Instalaciones físicas (condiciones ambientales, integridad de la estructura física, etc.)

3. Después de la inspección, el líder del equipo de recuperación debe reportarse al Centro de Operaciones de Emergencia (COE) para participar en una reunión de evaluación. En la evaluación del equipo utilice el formulario “Evaluar Estado de Equipo Crítico” que se incluye en la “Guía para Elaborar Planes de Continuidad de TIC”.

Activación del equipo de recuperación

En cuanto el equipo administrador de la recuperación comunica la decisión de activar el Plan, el Líder debe notificar a todos los miembros del equipo.

1. Determine cuales miembros del equipo deben ser requeridos para realizar los procedimientos siguientes: 1.1. Cumplir con los objetivos de recuperación 1.2. Asistir en los esfuerzos de salvamento 1.3. Asignación temporal para soportar otros departamentos

2. Elabore una lista del personal que no es requerido en las actividades iniciales de la recuperación.

3. Obtenga un lugar para hacer una reunión informativa y preparar el equipo de recuperación.

4. Contacte a todos los miembros de equipo y provea la información siguiente: 4.1. Identifique la ubicación designada para la reunión. 4.2. Identifique los requerimientos de tiempo para preparar a los miembros de equipo.

Sitio alterno de respaldo de datos

En el momento de la contingencia, el responsable de la recuperación de la información deberá determinar el sitio idóneo para la ubicación de los medios de respaldo de los datos del negocio, sea una localidad en el sitio (en el centro de datos) en caso que ella no se haya visto afectada, o bien una localidad fuera del sitio.



La información de localidades externas se encuentra y deberá documentarse en el formulario “Sitio Alterno de Respaldo de Datos” que se incluye en la “Guía para Elaborar Planes de Continuidad de TIC”.

Escalamiento de Notificaciones

1. Basado en la severidad de la situación, se deberá determinar lo siguiente:

1.1. El evento ha sido manejado apropiadamente y no se requieren notificaciones adicionales. Terminar situación de emergencia.

1.2. Las circunstancias del evento justifican notificaciones adicionales basado en lo siguiente:

1.2.1. El evento involucra daños a la propiedad y / o personas.

1.2.2. El evento involucra una interrupción potencial del negocio que excederá las horas de un día normal de trabajo.

2. Utilice el reporte “Composición de Equipos” que se incluye en la “Guía para Elaborar Planes de Continuidad de TIC” para notificar de las circunstancias del incidente a personal representativo de la organización. Suministre una breve descripción del incidente a los siguientes:

2.1. Coordinador del Plan de Continuidad

2.2. Encargado de TIC

3. Basándose en las circunstancias del evento se determinarán las acciones de respuesta inicial y el CPC dirigirá las actividades siguientes:

3.1. Si daños a personal han ocurrido, notifique a Recursos Humanos para que dirija los asuntos de notificación a los familiares y establezca las prioridades de la organización durante la crisis.

3.2. Si el acceso al edificio está permitido, inicie una inspección para evaluar los daños.

Evaluación de Daños

El Líder del PCTIC conducirá una inspección en el sitio, con el objetivo de determinar la extensión del daño en las áreas afectadas. Representantes de las áreas afectadas, de seguridad y de tecnología de información deben estar presentes para determinar las condiciones del sitio, y de los equipos de cómputo.

1. En caso de que el edificio haya sido afectado por el evento contingente

1.1. En caso necesario, obtenga autorización de las autoridades presentes (bomberos, policía, etc.) y envíe personal a las áreas afectadas del edificio.

1.2. Determine el equipo de emergencia que se requiere y adquiera los materiales necesarios para los miembros del equipo, basándose en las circunstancias de incidente. Considere, entre otros, los equipos siguientes: � Cascos y ropa de seguridad � Linternas � Cámara de video / fotografía instantánea o digital � Bloques de notas y lápices



� Radios (Walkie-talkies) � Cualquier otro que considere necesario.

2. Brinde una charla resumida, previa a la inspección, al personal de la compañía que visitará las áreas afectadas.

2.1. Discuta la información disponible, tal como la causa, condiciones ambientales, tiempos, consideraciones especiales, etc.

2.2. Haga que el personal revise los procedimientos de seguridad.

2.3. Discuta los objetivos de inspección y utilice el formulario “Evaluar Estado de Equipo Crítico” (PTC012) que se incluye en la “Guía para Elaborar Planes de Continuidad de TIC”.

3. Asigne objetivos de inspección a cada miembro del equipo de manera que se evalúen cuidadosamente los aspectos siguientes:

� Comunicaciones

� Sistemas

� Equipo de Cómputo

� Edificio (accesos y áreas de trabajo)

� Medios de almacenamiento

4. Viaje al sitio del daño y evalúe la magnitud del mismo. Entre otros, considere el área y su contenido:

� Estructura (interna y externa)

� Accesibilidad dentro del edificio

� Estado de las comunicaciones

� Estado del cableado y conexiones de la red

� Estado del servicio eléctrico

5. En caso necesario, trabaje con el contratista para elaborar un estimado de la reconstrucción de las áreas dañadas.

Establecer el COE

Basándose en los resultados de la evaluación de daños, el CPC determinará si las circunstancias del incidente justifican la activación de los demás miembros del equipo EAE y la notificación al la jefatura respectiva. Adicionalmente, basados en esas mismas circunstancias, se debe determinar la ubicación más recomendable para el Centro de Operaciones de Emergencias (COE). La determinación de la ubicación se hará con base en la información descrita en el documento “Ubicación del COE” que se incluye en la “Guía para Elaborar Planes de Continuidad de TIC”.

1. Contacte el lugar para el COE seleccionado y coordine el arribo del personal de soporte del EAE, así como del equipo de cómputo y los suministros.

2. Coordine la recuperación y entrega del material almacenado fuera de sitio hacia el COE.

3. Verifique que haya suficientes líneas telefónicas y teléfonos en operación.



4. Coordine la entrega del equipo de cómputo requerido.

5. Coloque bitácoras para todo el personal de que entra o sale del COE. Eso ayuda a documentar el uso del lugar y controlar al personal.

6. Utilizando diagramas, establezca y mantenga los cuadros de estado siguientes:

6.1. Mensajes generales

6.2. Ubicación del personal

6.3. Sesiones informativas

7. En cuanto el Centro de Operaciones de Emergencia (COE) esté operando, el Coordinador del Plan será el responsable por su operación continua.

Notificación a los miembros del EAE

Si se considera conveniente, todos los miembros del los equipos de recuperación serán contactados para que se reporten a una sesión informativa en el COE. 1. Suministre la información siguiente:

1.1. Información inicial del incidente. 1.2. Ubicación, número de teléfono del COE. 1.3. Fecha y hora de la sesión informativa.

Sesión Informativa

El CPC realizará una sesión informativa en el Centro de Operaciones de la Emergencia con todos los miembros del equipo invitados. Para ello utilice como guía el siguiente procedimiento:

1. Suministre la información siguiente, basándose en las circunstancias del evento contingente y en los resultados de la evaluación de daños. 1.1. Detalles del evento:

1.1.1. Tipo de Evento 1.1.2. Ubicación 1.1.3. Tiempo de la ocurrencia 1.1.4. Posible causa

1.2. Daños y fatalidades: 1.2.1. Número de personas muertas 1.2.2. Número de personas con heridas de gravedad 1.2.3. Estado de los heridos de gravedad 1.2.4. Posibilidad de heridos o muertos adicionales.

1.3. Edificaciones potencialmente dañadas 1.4. Acceso al edificio 1.5. Medios de Comunicación (Prensa)

1.5.1. Conocimiento del incidente por los medios (prensa) 1.5.2. Reacción de los reporteros en el sitio.

1.6. Cualquier instrucción especial o adicional que se considere conveniente y oportuna.



8. Recomendaciones de Recuperación

Una vez que se haya hecho la valoración del incidente, las actividades de respuesta y recuperación deben ser iniciadas inmediatamente.

Elaborar las Recomendaciones de Recuperación

Elabore recomendaciones sobre cuales estrategias deberán ser desarrolladas, considerando para ello los resultados del proceso de evaluación de daños y cualquier otro aspecto especial que podrían incluir, entre otros, el tiempo en que ocurre el evento y regulaciones externas o propias del negocio (por ejemplo, el cierre de fin de mes o año fiscal). El CPC dirigirá a los Líderes de los equipos de recuperación en lo siguiente:

1. Elabore una lista de prioridades de recuperación de la plataforma, basándose en las Tiempos Máximos de Interrupción (TMI) establecidos según tabla incluida en la “Guía para Elaborar Planes de Continuidad de TIC”. Actualice esta lista con cualquier cambio necesario, considerando los recursos disponibles y requerimientos inmediatos de TI.

Revisar y Finalizar las Recomendaciones de Recuperación

1. El CPC evaluará el evento suscitado y determinará de inmediato la necesidad de actualizar el COE.

2. Si el COE no está disponible inmediatamente, entonces:

2.1. Coordine para determinar el tiempo estimado en el cual estará disponible.

2.2. Obtenga la identificación y el tiempo estimado de la duración de la interrupción de los servicios de Tecnología de Información.

9. Seguimiento del Evento

El estado del evento y el reporte de las acciones de recuperación debe ser mantenido por el CPC. Para realizar eso, algunas sugerencias se ofrecen a continuación:

1. Controle el estado del evento brindando seguimiento a las actividades de respuesta y recuperación del personal involucrado en las mismas. Considere, al menos, lo siguiente:

1.1. Tipo de evento

1.2. Áreas funcionales afectadas

1.3. Actividades planeadas

2. Documente la bitácora del avance de las tareas en secuencia cronológica. Utilice para ello el formulario “Resumen del Estado del Evento” (PTC011), incluido en la “Guía para Elaborar Planes de Continuidad de TIC”. El propósito de este reporte de estado es asistir el control y las comunicaciones. Es conveniente considerar la utilización de múltiples formularios para documentar actividades concurrentes.

2.1. Actividades de soporte y recuperación de Tecnología de Información

2.2. Actividades de restauración de las instalaciones (edificio) y/o del COE.

3. Brinde seguimiento apropiado para la pronta solución de asuntos que podrían obstaculizar la ejecución oportuna de tareas.

3.1. Asuntos de seguridad

3.2. Adquisición de recursos



3.3. Disponibilidad de los proveedores

3.4. Asuntos del personal

10. Anexo I – Plantilla para control del desarroll o de las fases La siguiente plantilla se propone con el fin de dar un control en el desarrollo de las diferentes etapas de la realización de un plan de continuidad.

Paso Plan de Continuidad en TIC Fecha Inicio

Fecha Final Responsable

1 Análisis de Riesgos (análisis de Impacto)

2 Desarrollo de Estrategias de Recuperación de las Operaciones

3 Desarrollar e implementar el Plan de Recuperación ante Desastres (DRP)

4 Desarrollar programas de entrenamiento y concientización

5 Ejercitar y dar mantenimiento al DRP

6 Procedimiento de mejora continua



11. Anexo II – Guía para la elaboración de Analisis de Riesgos

Introducción

La seguridad y el control dentro de las operaciones diarias de un negocio es una preocupación constante de sus clientes. Reducir el impacto de potenciales amenazas se logra estableciendo controles adecuados, procedimientos y prácticas antes de que los eventos de interrupción o desastre se materialicen. El Análisis de Riesgos en Tecnología de Información y Comunicaciones se concentra en la identificación de potenciales amenazas y la evaluación de los controles existentes con el propósito de hacer las recomendaciones correspondientes para la mejora en la administración y operación de la plataforma tecnológica. El objetivo de esta actividad es reducir la probabilidad de una amenaza potencial y reducir el impacto que puede provocar un evento desastroso o una interrupción significativa en los servicios.

Las actividades principales son las siguientes:

� Identificar las amenazas físicas y las medidas correspondientes para la mitigación en el sitio, incluyendo amenazas internas y externas, seguridad y controles ambientales, seguridad y procedimientos de respuesta a incidentes, procedimientos de respaldo y recuperación de datos, y prácticas de personal.

� Análisis de vulnerabilidad, identificar amenazas y debilidades en los controles que pudieran no haber sido diseccionados, o identificar posibles mejoras que puedan implementarse.

� Desarrollar sugerencias y recomendaciones para reducir la probabilidad de ocurrencia de las amenazas, incluyendo acciones de prevención y correctivas.

Los objetivos de un Análisis de Riesgos son evaluar las amenazas físicas en contraposición con los controles para reducir la probabilidad de ocurrencia, y para mitigar el impacto de dichas amenazas. Los tipos de controles incluyen políticas y procedimientos de seguridad física, preparación para la respuesta a incidentes, y planes en sitio para implementar procedimientos y políticas para controles adicionales dentro de la organización. Los resultados de esta investigación se documentan en un reporte y se comunican al Comité de Dirección de la Continuidad.

Los resultados del trabajo permitirán determinar:

� La probabilidad de potenciales amenazas identificadas.

� La vulnerabilidad de diversas funciones dentro de la compañía, para cada una de las amenazas.

� El costo efectivo de los controles en el sitio.

� La priorización requerido para la implementación de los controles.

� El cronograma de implementación de los controles requeridos.



Desarrollo de Análisis de Riesgos (definiciones)

Antes de iniciar con la metodología de ejecución del Análisis de Riesgos, es importante aclarar algunos conceptos que están asociados directamente con el tema y cuyo dominio es relevante. ¿Qué es Riesgo?

Los riesgos, que pueden ser naturales o provocados por el hombre, representan la exposición a la pérdida dentro de una organización. Los potenciales riesgos son típicamente medidos en términos de probabilidad de ocurrencia y el impacto generado en caso que los mismos se materialicen. ¿Qué es Vulnerabilidad?

La vulnerabilidad se mide con relación al nivel de sensibilidad que tiene la organización a que uno de los riesgos se materialice. ¿Qué es Probabilidad?

La probabilidad mide la capacidad de ocurrencia del riesgo en el tiempo, considerando niveles de (como ejemplo): muy poco probable, poco probable, moderada, probable y casi cierta. ¿Qué es Impacto?

El impacto mide el nivel de daño provocado una vez manifestado el riesgo. Este nivel de impacto

se puede medir (como ejemplo) con la calificación siguiente: insignificante, menor, moderado,

significativo o catastrófico.

¿Qué es el nivel de riesgo?

Grado de exposición al riesgo que se determina a partir del análisis de la probabilidad y

vulnerabilidad de ocurrencia del evento y de la magnitud de su consecuencia potencial sobre el

cumplimiento de los objetivos fijados. Permite establecer la importancia relativa del riesgo.

El análisis de Riesgos (categorías de riesgos)

Para el desarrollo del análisis de riesgos deberá considerar una serie de categorías de riesgos sobre los cuales de acuerdo a estudios de mercado, se presentan la mayoría de interrupciones y desastres que afectan a TIC en cualquier organización. Las áreas que como mínimo deberá evaluar son las que se indican en las tablas de las páginas siguientes. Para cada evento se muestra un ejemplo de los eventos que podría considerar para realizar la evaluación, no obstante no deberá únicamente limitarse a los descritos. El objetivo principal es evaluar aquellas situaciones (eventos) a partir de las cuales se pueda suscitar una interrupción de los servicios de TIC.



Categorías de Riesgos

Ejemplo de aspectos mínimos que puede considerar

Interrupción eléctrica � Fuentes alternas de generación eléctrica: UPS y plantas eléctricas; � Mantenimiento de las fuentes alternas de generación eléctrica; � Estado de la instalación eléctrica y capacidad eléctrica instalada; � Lámparas de emergencia; � Señalamiento iluminado de salidas y puertas de emergencia.

Fallos en Hardware � Equipo de cómputo utilizado y obsolescencia; � Capacidad de redundancia entre servidores; � Monitoreo de problemas en los servidores; � Contratos de mantenimiento preventivo y correctivo; � Condiciones físicas y ambientales (limpieza, humedad, temperatura).

Fallos en Software � Desarrollo local de aplicaciones (metodologías/ estándares); � Cambios y configuración en aplicaciones; � Trascendencia de los sistemas incluidos en el estudio.

Fallos en Comunicaciones

� Soporte técnico de los equipos utilizados; � Mantenimiento preventivo y correctivo de los equipos de comunicación.

Desastres naturales � Pólizas de seguro vigentes; � Brigadas de atención ante situaciones de emergencia; � Capacitación al personal; � Rutas de evacuación; � Iluminación de pasillos y puertas y salidas de emergencia.

Incendio � Pólizas vigentes de seguro; � Sistemas automáticos y manuales contra incendio (gabinetes, extintores,

aspersores); � Uso de materiales retardantes del fuego; � Almacenamiento de material combustible; � Detectores de humo revisados regularmente.

Fallos en Respaldos � Procedimientos para respaldo y recuperación de información, fuentes,

objetos, documentación, y configuración de los sistemas; � Periodicidad de los respaldos; � Facilidades y protección para el almacenamiento dentro y fuera de sitio; � Configuración de los discos duros de los servidores; � Documentación actualizada sobre procedimientos de respaldo y

recuperación.

Categorías de riesgos Ejemplo de aspectos mínimos que puede considerar

Virus � Programa antivirus instalado en computadoras y servidores; � Configuración y actualización del software antivirus; � Consultas regulares de fuentes de información para actualizaciones

sobre virus; � Capacitación al personal para identificar potenciales fuentes de

ataque de virus; � Políticas para el ataque de virus.

Violaciones a la Seguridad física

� Seguridad física para el ingreso al edificio, oficinas y cuartos de servidores y equipos de comunicación; � Capacitación al personal para detectar situaciones que puedan

representar riesgo o cuestionar la presencia de personas desconocidas o sin identificación; � Sistemas de seguridad: circuitos cerrados de televisión, sensores de

movimiento, alarmas; � Revisión y control de salida e ingreso de equipo de cómputo;



� Utilización de bitácoras para el registro de ingresos.

Intrusión (hackeo) � Procedimientos para otorgamiento de acceso a las aplicaciones y

políticas de acceso lógico; � Procedimientos para el acceso a los recursos tecnológicos (redes y

aplicaciones); � Administración y configuración de “firewalls”; � Monitoreo de los accesos tanto legítimos como ilegítimos; � Disponibilidad de herramientas para el monitoreo de la seguridad.

Recurso Humano � Dependencia en el personal; � Capacitación; � Documentación de las funciones del personal;

Los riesgos identificados en el análisis deberán ser resumidos en la tabla (ARV001) del Anexo II, para concluir sobre la probabilidad y el impacto asociados a cada situación (ARV002).

Metodología

Con el propósito de recabar la información necesaria para el análisis de las amenazas y los controles relacionados con cada uno de esos eventos, se podrá realizar reuniones con funcionarios del área de Informática y otras áreas administrativas que pudieran estar involucradas en el análisis de los eventos citadas en las tablas anteriores. Es recomendable que de cada reunión se emita una minuta que resuma la información más relevante y que será el sustento de las conclusiones que se incorporen en el análisis de riesgos.

Finalmente, se efectúan visitas, inspecciones y valoraciones del grado de riesgo asociado en cuartos de servidores, cuartos de comunicación y otras áreas del edificio donde haya como ejemplo equipo de emergencia tal como extintores.

Captura de la información de riesgos

Con el propósito de facilitar la generación de la estrategia de riesgos y el seguimiento posterior del análisis, se deberá completar una tabla donde se resumen los riesgos identificados, la recomendación de implementación o mejora de control para tratar el riesgo y el ente (persona o área del negocio) responsable por la implementación de la recomendación.

La tabla a utilizar será la siguiente: (ARV001)

Captura de la Información de Riesgos - ARV001

Código Área: DRxxxx-xxx-xxx Versión: x.0 Fecha: dd-mmm-aaaa



Plan de Continuidad TIC Responsable:

Un ejemplo de cómo se debe completar la tabla, es el siguiente:

Categoría del Riesgo

Descripción del Riesgo

Descripción del Impacto

FechaNivel de Impacto

Nivel de Probabilidad

Nivel de Riesgo

1 Interrupción eléctrica

Ausencia de planta eléctrica

Interrupción del servicio de TI en caso de falta de sistema eléctrico

Agosto 29, 2006 Critico Moderada Critico

2 Comunicaciones Fallo en la línea de comunicación

Pérdida de la comunicación hacia la Dirección Regional

Agosto 29, 2006 Insignificante Poco probable Bajo

3 Respaldos No hay respaldos fuera de sitio

Pérdida de información en el sistema de Farmacia (SIFA)

Agosto 29, 2006 Critico Poco probable Crítico

Análisis de probabilidad, impacto y riesgo

Como parte de las actividades que se deben desarrollar para completar la tabla anterior, deberá identificar el nivel de probabilidad y el nivel de impacto asociados con cada riesgo. Para identificar dichos niveles adecuadamente, deberá utilizar las tablas de la página siguiente, y determinar con base en ellas, cual es cada nivel asociado al riesgo correspondiente. Para la definición de categorías de riesgo considere la tabla siguiente:

:

Categorías de Riego Cod Descripción

Operacional O El efecto afecta la operativa de la institución

Legal/ regulatorios L El efecto podría afectar la institución ante una demanda o

sanción de carácter regulatorio.

Financiero F El efecto afecta las finanzas de la institución.

Imagen I El efecto afecta la imagen y servicio de la institución



Para la calificación de la probabilidad considera la tabla siguiente

Niveles de Probabilidad

Descripción

Casi cierta 10 Es muy probable que ocurra un evento de esta naturaleza.en un periodo de tres meses.

Probable 7 Es probable que ocurra un evento de esta naturaleza en un periodo de 3 a 6 meses.

Moderada 5 El evento ocurrirá en algún momento en un periodo de 6 meses a un año.

Poco probable 3 Es poco probable que el evento suceda pero podría ocurrir en algún momento de un periodo de un año a dos años.

Muy poco probable 1 Es muy poco probable que el evento se presente en un periodo

más de 2 años y no se detectaron vulnerabilidades que aumenten su probabilidad de ocurrencia.

Para la calificación del impacto considera la tabla siguiente:, vale aclarar que estas

descripciones ir acompañadas de un elemento de nivel o calidad de servios o económico.

Niveles de

Impacto

Descripción

Crítico

10 El evento provoca una interrupción completa de la Tecnología en Informática y de todas sus operaciones. Los procesos críticos del negocio no tienen acceso a las instalaciones y tampoco a los recursos de información.

Significativo 7 El evento provoca una interrupción entre parcial y completa de la Tecnología en

Informática y afecta a todos sus procesos.

Moderado 5 El evento provoca una interrupción en los servicios de TI y esto afecta los

procesos, pero las actividades críticas no son interrumpidas.

Menor

3 El evento genera un leve impacto en los procesos, pero no ocasiona una interrupción importante en las operaciones. La interrupción de los servicios de TI afecta a menos de un 30% de los usuarios y dura lo suficiente para afectar levemente sus operaciones.

Insignificante

1 El evento no provoca un impacto en los procesos. La interrupción de los servicios de TI afecta a uno o algunos usuarios, pero no dura lo suficiente para provocar un impacto en sus procesos.



Para cada categoría de riesgo, se deberá especificar el nivel de impacto y el nivel de Probabilidad según las tablas respectivas indicadas anteriormente. Luego de esto, deberá determinar el nivel de riesgo asociado, y para esto deberá, revisar el valor asignado a cada nivel de Impacto y nivel de probabilidad y multiplicar dichos valores. Para determinar el nivel de riesgo debe comparar los valores resultantes de acuerdo a los rangos de los criterios de calificación de los riesgos establecidos en la siguiente tabla. Para obtener el nivel de riesgo asociado únicamente deberá “cruzar” en la matriz la probabilidad versus el impacto y el color resultante representará el nivel asociado de riesgo. Para la definición de los criterios de calificación de Riesgos considere la tabla siguiente:

Matriz de Riesgo para el Riego Operativo

INSIGN MENOR MODER SIGNIF. CRITICO

ACTO

Riesgo Rango Inferior Rango Superior

Muy Alto 70 100

Medio 35 69

Medio 16 34

Medio 6 15

Muy Bajo 1 5

10 30 50 70 100

7 21 35 49 70

5 15 25 35

50

3 9 15 21 30

1 3 5 7 10

P

R

O

B

A

B

I

L

I

D

A

D



Un ejemplo es el siguiente: si se considera un riesgo con una probabilidad Moderada y un impacto Significativo, la nivel asociado de riesgo es Crítico, tal como se muestra en la matriz. Al finalizar esta fase, deberá tener un inventario de riesgos completo en la tabla muestra de la página 9, y una representación de los riesgos en la matriz, tal cual se muestra en el ejemplo siguiente:

La representación del riesgo puede hacerse considerando dos situaciones:

1. Representando cada uno de los riesgos por separado; o,

2. Representando el mayor de los niveles de riesgo asociados a un único evento. (este es el caso de cómo se representó en la matriz anterior).

Finalmente aquellos eventos para los cuales no se identifica ningún riesgo, no se representan en la matriz y deberá entenderse que en aquellos eventos para los cuales su respectiva letra de identificación no se ve reflejada en la matriz, no poseen riesgos asociados.

Desarrollo de estrategias de riesgos

Luego de la identificación de los riesgos en TIC, se deberá establecer la(s) estrategia(s) tendientes a mitigar los riesgos identificados. Información relacionada es la definición de las acciones a seguir para lograr que la estrategia se implemente y el establecimiento de una persona responsable por el seguimiento y logro de la estrategia de continuidad seleccionada.

Cada una de las estrategias que se desarrollen para cada riesgo, estarán orientadas a disminuir la probabilidad y/o el impacto de cualquiera de los riesgos identificados en el análisis. Se debe aclarar que estas estrategias no forman parte de una estrategia durante o después de un evento de contingencia. La estrategia durante o después del evento se planteará en el documento Plan de Continuidad.

Para esto, considere agregar a la tabla mostrada (ARV001), lo siguiente: (ARV002).

Simbología del Riesgo: Bajo Moderado Alto Crítico



Desarrollo de estrategias de riesgos- ARV002


Plan de Continuidad TIC Responsable:

Un ejemplo de esta sección, considerando los riesgos del ejemplo anterior, es el siguiente:

Categoría del Riesgo

Descripción del Riesgo

Estrategia de Mitigación

Acciones a seguir

Responsable Estado

1 Interrupción eléctrica

Ausencia de planta eléctrica

Disponer de una planta eléctrica para cubrir necesidades de TIC y del Área de Salud

Iniciar proceso de compra con la correspondiente justificación

Dirección y Administración del Área de Salud

En proceso

2 Comunicaciones Fallo en la línea de comunicación

Disponer de una línea alterna para la comunicación en el momento que el nivel de riesgo se incremente

Contratar una línea de comunicación alterna


En proceso

3 Respaldos No hay respaldos fuera de sitio

Llevar respaldos fuera de sitio

Identificar el sitio donde llevar los respaldos


En proceso

Una vez completadas la tabla y la matriz de riesgos, a ambas se le deberá dar un seguimiento permanente con el fin de identificar nuevos riesgos que eventualmente podrían afectar la continuidad de la plataforma de TI, además de dar seguimiento y garantizar la ejecución exitosa de las estrategias tendientes a la reducción de los riesgos ya identificados. El seguimiento de este análisis deberá hacerse al menos dos veces al año para mejorar en todo momento la mitigación de todos aquellos riesgos que eventualmente podrían aparecer en el tiempo.



12. Anexo III – Guía para elaborar planes de contin uidad de la Gestion en TIC

Introducción

Como parte del plan de continuidad a desarrollar a partir de este manual, podrá encontrar en esta sección documentos que deberá preparar previo a la manifestación de un evento de interrupción, mientras que otros documentos incorporados en esta Guía, serían utilizados después de la contingencia o evento de desastre o interrupción.

La información o documentos que deberá tener preparados previos a la manifestación de cualquier desastre y/o como parte del plan de continuidad son los siguientes:

• Carátula de Plan de Continuidad de la Gestión de TIC. • Control de revisión y aprobación del documento (PTC000). • Información de la Unidad (PTC001, PTC002); • Inventario de hardware y software (PTC003); • Análisis de Riesgos (ARV001, ARV002); • Tiempos Máximos de Interrupción (PTC004); • Organización para la Continuidad (PTC005); • Composición de Equipos (PTC006); • Información de Contactos Externos (PTC007); • Ubicación del Centro de Operaciones de Emergencia (COE) (PTC008); • Sitio alterno de respaldo de datos (PTC009); • Matriz de Ensayos del Plan (PTC010); • Procedimientos de Recuperación para la plataforma de TIC Hardware (PTC015); • Procedimientos de Recuperación para la plataforma de TIC Software (PTC016); • Procedimientos de Recuperación para la plataforma de TIC Comunicaciones (PTC017); • Resumen del Estado del Evento (este se utilizará luego de un evento de desastre) (PTC011); • Evaluar Estado de Equipo Crítico (este se utilizará luego de un evento de desastre)

(PTC012). • Ensayos del Plan (PTC013). • Mantenimiento del Plan (PTC014). • Plan de capacitación (PTC018). • Presupuesto equipo para contingencias (PTC019). • Protocolo de Escalación de eventos (PTC020). • Anexo de Abreviaciones.



Plan de Continuidad de la Gestión en TIC (indicar el lugar)

Carátula de Plan de continuidad de la Gestión en TI C

Caja Costarricense de Seguro Social

Dirección de Tecnologías de Información y Comunicaciones

Administración de la Continuidad de la Gestión

Plan de Continuidad de la Gestión en Tecnologías de Información y Comunicaciones

Area:__ (indicar el lugar)____ DRxxx-xxx-xxx

Versión 1.0 – xxxx 2007



CONTROL DE LLENADO DE MATRICES FECHA LLENADO

• Control de revisión y aprobación del documento (PTC000). • Información de la Unidad (PTC001, PTC002); • Inventario de hardware y software (PTC003); • Análisis de Riesgos (ARV001, ARV002); • Tiempos Máximos de Interrupción (PTC004); • Organización para la Continuidad (PTC005); • Composición de Equipos (PTC006); • Información de Contactos Externos (PTC007); • Ubicación del Centro de Operaciones de Emergencia (COE) (PTC008); • Sitio alterno de respaldo de datos (PTC009); • Matriz de Ensayos del Plan (PTC010); • Procedimientos de Recuperación para la plataforma de TIC Hardware (PTC011); • Procedimientos de Recuperación para la plataforma de TIC Software (PTC012); • Procedimientos de Recuperación para la plataforma de TIC Comunicaciones (PTC013); • Resumen del Estado del Evento (este se utilizará luego de un evento de desastre) (PTC014); • Evaluar Estado de Equipo Crítico (PTC015).

Matriz ensayos del Plan (PTC016). • Ensayos del Plan (PTC017). • Mantenimiento del Plan (PTC018). • Procedimiento alterno de trabajo. (PTC019). • Protocolo de Escalación de eventos (PTC020). • Plan de capacitación (PTC021). • Presupuesto equipo para contingencias (PTC022).



Control de revisión y aprobación del documento (PTC000)

Historial de revisiones

Versión Autor Fecha Revisión

Control de aprobación

Responsable Firma Fecha de Aprobación

1 2 3 4 5

Control de ensayos

Responsable Fecha Resultados 1 2 3 4 5

Nota: Ver Políticas de Continuidad en el Manual de Políticas Institucional para más detalles de responsabilidades.

13. Historial de revisiones

Versión Fecha Descripción Razón Cambio Responsables



14. Plan de continuidad. Complete la información general solicitada en la tabla siguiente: (PTC001 y PTC002)

Información de la Unidad ( PTC001, PTC002) Complete la información general solicitada en la tabla siguiente: (PTC001)

Nombre de la Unidad:

Dirección:

Ciudad

Número de teléfono Unidad programática

LIDER: La siguiente persona estará a cargo de gestionar la crisis y será el portavoz de la unidad en caso de emergencia.(PTC002)

Nombre Contacto Primario de Emergencia

Número de Teléfono

Número Alternativo

Correo electrónico

Unidad Programática

SUPLENTE: En caso que el funcionario anterior no esté disponible, será relevado por:

Nombre Contacto Segundario de Emergencia

Número de Teléfono

Número Alternativo

Correo electrónico

Unidad Programática


Plan de Continuidad TIC Aprob:: (líder o coordinador del plan) Firma:

Cada tabla es aprobada por quien hizo el plan, el plan en su totalidad lo aprueba, ya sea el administrador y director

Como parte del Plan de Continuidad de TIC se deberá contar con un inventario, para lo cual puede utilizar el formato de información siguiente: (PTC003)

Inventario de hardware y software - PTC003

Nombre del

Equipo

Sist. Operat

ivo

Inform. d e los

Procesadores

Infor. de la

Memoria

Unidades de

Almacena-miento

Unidades de

respaldo

Base de

datos

Equipos de comunic.

Sistema de

Inform.

Numero de placa

ccss

Nivel Criticidad (A,M,B)

Alto: La ausencia de dicho hardware o software para interrumpe toda la operación de la Oficina Regional.

Medio : La ausencia de dicho hardware o software para interrumpe varios usuario con un TMI con una ventana de tiempo corto.

Bajo : La ausencia de dicho hardware o software para interrumpe un usuario con un TMI con una ventana de tiempo amplio.

Recomienda revisar el inventario una vez al año o cuando se presenta un cambio significativo en los equipos principales.

Código Área: DRxxxx-xxx-xxx

Versión: x.0 Fecha: dd-mmm-aaaa

Plan de Continuidad TIC Aprob: (líder o coordinador del plan) Firma: Al Formato anterior puede adicionar cualquier otra información que usted considere pertinente para el adecuado reconocimiento del equipo y sus correspondientes relación de dependencia o de operación con otros equipos de la plataforma.

Análisis de Riesgos

El análisis de riesgos es un componente fundamental en el desarrollo de un plan de continuidad. En esta sección se deberá incluir tanto la Matriz de Resultados del Análisis de Riesgos, como las tablas de detalle de los riesgos identificados (ARV001 y ARV002). Tabla de riesgos identificados (ARV001) ARV002

Captura de la Información de Riesgos y desarrollo d e estrategias de Riesgos

Titulo del Riesgo Descripción del Riesgo

Descripción del Impacto Fecha

Nivel de Impacto

Nivel de Probabilidad

Nivel de Riesgo

Estrategias de Mitigación

Acciones a Seguir Responsable Estado

1 2 3 4 5

Código de Área: DRxxxxxxxxxx Versión: x.0 Fecha: dd-mm-aaaa

Plan de Continuidad TIC Responsable

La Categorías de Riesgo se encuentran incluidas en la pagina 32 del Manual para Elaborar Planes de Continuidad en TIC y la Descripción indicara como esa categoría de Riesgo impactará a la unidad e Tecnología. Por ejemplo: Ejemplo Categoría : es Interrupción Eléctrica Descripción: Ausencia de una Planta de abastecimiento de energía eléctrica.

Estrategias durante y después de la manifestación d e los riesgos. Categoría del Riesgo: _____________________________ __________________________ Descripción del riesgo : ______________________________________________________ Acciones durante la manifestación del riesgo

Acción Iniciales ID Ref.

Acciones después de la manifestación del riesgo.


Procedimientos para regreso al sitio principal


Contactos requeridos

Empresa Nombre de referencia Teléfonos

Manual para Elaborar un Plan de Continuidad de la Gestión en TIC TIC-ASC-CGN-0001

Continuidad de la Gestión en Tecnología de Información y Comunicaciones Versión 1.0


Tiempos Máximos de Interrupción (PTC004)

Los Tiempos Máximos de Interrupción (TMI) deberán ser definidos en conjunto con las áreas usuarias de los sistemas de información. Su propósito es establecer cuanto tiempo como máximo podrán los procesos de TIC y que apoyan a las áreas, estar sin operación antes de que se cause daño a la organización. Además, con la definición de estos TMI el personal de TIC deberá establecer las prioridades correspondientes para en caso de una interrupción total, realizar una recuperación organizada de la plataforma tecnológica, que permita responder a los TMI aquí definidos y dar la atención a las áreas usuarios, en primera instancia que provean servicios considerados como críticos para la organización, hasta concluir con aquellos servicios menos críticos para el negocio.

Complete en la tabla siguiente (PTC004), para cada área de negocio, cuáles son las funciones afectadas en cada una de ellas y el TMI factible, definido en acuerdo con el área usuaria. Se incluye en la primera línea un ejemplo de la información a completar.

La Criticidad estará definida por escalas para posteriormente clasificar la prioridad y criticidad lo que dependerá de cada área. Ejemplo: menos de cuatro horas, un día, dos días, cinco días, dos semanas, etc. Los factores de riesgos se pueden clasificar en aspectos Operativos (O), Imagen(I), Legales (L) y Regulatorios (R). La definición del TMI se puede hacer en minutos, horas, días etc.

Tiempos Máximos de Interrupción (PTC004)

Área, U.P. Funciones afectadas

Sist. Informac. de apoyo

Factor Riesgo TMI TR TMIR Criticidad

� Recursos Humanos

� Generación de la planilla para pago a empleados

Regulatorio Operativo Legal

120 min

30 min 90 min

ALTO Menor 120m

� Contabilidad � Cierre mensual


Plan de Continuidad TIC Aprob:(Puede ser Asist Adminitrativo) Firma:

Niveles de Criticidad

Alto El TMI de Menor de XX horas.

Medio El TMI esta entre xx y yy horas

Bajo El TMI es mayor que yy horas.

Para el caso del ejemplo se deberá entender que el tiempo máximo que se puede interrumpir el proceso de generación de la planilla es de dos horas, antes de que se genere un problema que pudiera poner en riesgo el pago de la planilla a los empleados. De igual forma en el área de contabilidad, el cierre mensual puede verse afectado por un máximo de dos horas, antes de que inicie la afectación del proceso para la empresa.




Organización para la Continuidad (PTC005)

Deberá incluir como parte del Plan de Continuidad, información general de la organización, del personal para la continuidad de TIC (PTC005). Un ejemplo de dicha organización es el siguiente:

Organización para la Continuidad - PTC005

Nota: Como una consideración adicional, en aquellos casos donde el personal de apoyo al plan es reducido se podrían complementar con personal de la Dirección Regional, siempre y cuando exista previo acuerdo entre las partes.


Plan de Continuidad TIC Aprob: (líder o coordinador del plan) Firma:

Cada uno de los cuadros de equipos deberá llevar los nombres de las personas que conforman cada equipo, además de la misión, visión, objetivo, organigrama, etc, de la unidad.

Equipo Recuperación hardware

Equipo Recuperación Software y

Aplicaciones

Equipo Recuperación Equipos y Líneas de

Comunicación

Equipo Administrador de Tecnología de Información U.P:




Composición de equipos (PTC006) El Centro de Operaciones de Emergencia (COE) es el sitio desde donde se coordinarán y supervisarán las acciones de recuperación del desastre (PTC006).

Composición de equipos - PTC006

Equipo U.P. (*)

Nombre del Empleado Rol Teléfono Celular Dirección


Plan de Continuidad TIC Aprob:: (líder o coordinador del plan) Firma: Nota: Los roles se especifican en la parte teórica del plan en la paginas 13 del Manual para Elaborar Planes de Continuidad en TIC.




Información de contactos externos (PTC007) Complete para sus proveedores y otros contactos externos, la información que le permitirá localizarlo fácilmente, en el momento que requiera de su asistencia. Complete para ello la información de la tabla siguiente: (PTC007)

U.P.

Compañía

Servicios

Tel. Cía.

Fax Cía.

Dirección Cía.

E-mail Cía.

Contactos E-mail Teléfono Celular Beeper

Código Área: DRxxxx-xxx-x Versión: x.0 Fecha: dd-mmm-aaaa

Plan de Continuidad TIC autor:: (Persona que recopila la información de contactos)




Ubicación del Centro de Operaciones de Emergencia ( PTC008) El Centro de Operaciones de Emergencia (COE) es el sitio desde donde se coordinarán y supervisarán las acciones de recuperación del desastre. Para esto complete la información que se solicita. (PTC008)

SITIO No. 1

U.P.

Ubicación; Dirección: Teléfonos: Contactos:

#1 Nombre:

Puesto: Rol: Tel. Hab.: Tel. Celular: Beeper: Dirección:

#2 Nombre:

Puesto: Rol: Tel. Hab.: Tel. Celular: Beeper: Dirección:




Sitio Alterno de Respaldo de Datos (PTC009)

En las tablas siguientes, documente los datos de los lugares donde se almacenan los respaldos de datos y cualquier otra “Nota” requerida como referencia del procedimiento para acceder a dichos sitios y los protocolos para enviar y retirar los respaldos del sitio. (PTC009) SITIO No. 1

U.P. Ubicación; Dirección. Teléfonos: Tipo datos:

Contactos:

Nombre:

Tel. oficina Frecuencia

SITIO No. 2

U.P.: Ubicación: Dirección Teléfonos: Tipo datos:

Contactos:

Nombre:

Tel. oficina Frecuencia

Notas:




Matriz de ensayos del plan (PTC010)

En la matriz de pruebas del plan, deberá planear la ejecución de diversos tipos de ensayos, durante un período de un año. Para esto, utilizando la matriz descrita, puede planear el tipo de ensayo y en qué mes se deberá llevar a cabo el mismo. Puede completar la matriz indicando qué día del mes planea llevar a cabo el ensayo o bien, únicamente marcar con “x” el mes y posteriormente, iniciado ese mes, establecer la fecha exacta de ejecución del ensayo y el planeamiento que esto implica, incluyendo por ejemplo la preparación del personal si esto fuese necesario. (PTC010)

Calendario anual de Ensayo - PTC010

Año:__________

Tipo de Ensayo

U.P. EN

E

FE

B

MA

R

AB

R

MA

Y

JUN

JUL

AG

O

SE

T

OC

T

NO

V

DIC

Presupuesto

1-

2-

3-

4-

5-

6-


Plan de Continuidad TIC autor::Puede ser firmado por el responsable y/o por el suplente




Procedimientos de Recuperación (hardware)(PTC011)

Procedimiento de Recuperación

{Nombre del hardware}

Control de revisión y aprobación del documento

Historial de revisiones


Control de aprobación Responsable Firma Fecha de Aprobación

1 2 3 4 5

Control de ensayos Responsable Fecha Resultados

1 2 3 4 5

NOTA: este documento deberá revisarse al menos una vez al año y los procedimientos deberán

ser probados en su totalidad con la misma periodicidad.




Información General

Objetivos del documento {Documente cuál es el objetivo de este documento} Distribución {Documente a qué personas o áreas deberá hacer llegar copia de este documento y a través de qué medio se le hará llegar} Integrantes del equipo de recuperación

Principal Suplente Líderes del equipo {nombre completo} {nombre completo} Miembro No. 1 {nombre completo} {nombre completo}




Información general del hardware

{complete la información requerida, puede adicionar la información que considere pertinente} Marca y modelo Dirección IP Procesadores

Sistema Operativo

Versión Parches

Base de datos Versión Parches

Discos Duros

Especificación técnica Área de SWAP Tarjetas controladoras

Tarjeta de red Especificación técnica Redundancia

Memoria Cantidad Tolerancia a fallos (ECC memory)

Fuente de poder Especificación técnica Redundancia

Unidad de respaldo

Marca y modelo Tipo de cinta Software usado

Garantía de fábrica

Proveedor y contacto Fecha de Vencimiento

Contrato de mantenimiento Proveedor y contacto Fecha de vencimiento

Otros




Recuperación del hardware

Estrategia de recuperación {Detalle la generalidad de la estrategia a seguir para la recuperación} Acciones requeridas previo o durante el proceso de recuperación

Acción Completado (S/N) Iniciales ID Ref.

Procedimientos de validación y sincronización con o tros equipos


Procedimientos para regreso al sitio principal


Otros procedimientos posteriores al evento


Contactos requeridos (empleados involucrados con el equipo, proveedores, etc.)


Notas:




Procedimientos de Recuperación (Sistema de Informac ión o Aplicación)(PTC012)


{Nombre del Sistema de Información o aplicación}

Control de revisión y aprobación del documento Historial de revisiones


Control de aprobación Responsable Firma Fecha de Aprobación

1 2 3 4 5


1 2 3 4 5

NOTA: este documento deberá revisarse al menos una vez al año y los procedimientos deberán ser probados en su totalidad con la misma periodicidad.




Información General Objetivos del documento {documente cuál es el objetivo de este documento} Distribución {documente a qué personas o áreas deberá hacer llegar copia de este documento y a través de qué medio se le hará llegar} Integrantes del equipo de recuperación


Información general de la aplicación {complete la información requerida, puede adicionar la información que considere pertinente} Versión en producción

Sistema operativo base

Versión Parches

Plataforma base

Servidores Equipos de comunicación

Enlaces Otros




Recuperación de la aplicación Estrategia de Recuperación {Detalle la generalidad de la estrategia a seguir para la recuperación} Recursos requeridos previo o durante el proceso de recuperación

ID Recurso Ubicación Responsable

Instalación de la aplicación


Procedimientos de validación en la instalación de l a aplicación


Procedimientos y parámetros para configurar la apli cación






Notas:




Procedimientos de Recuperación (Equipo o línea de c omunicación. (PTC013)


{Nombre del equipo o detalle de la línea de comunic ación}

Control de revisión y aprobación del documento Historial de revisiones


Control de aprobación Responsable Firma Fecha de

Aprobación 1 2 3 4 5


1 2 3 4 5

NOTA: este documento deberá revisarse al menos una vez al año y los procedimientos deberán ser probados en su totalidad con la misma periodicidad.




Información General Objetivos del documento {documente cuál es el objetivo de este documento} Distribución {documente a qué personas o áreas deberá hacer llegar copia de este documento y a través de qué medio se le hará llegar} Integrantes del equipo de recuperación


Información general del equipo de comunicación {complete la información solicitada, puede adicionar la información que considere pertinente} Marca y modelo Dirección IP

Sistema Operativo

Versión Parches

Puertos

Cantidad Tipo

Memoria Cantidad Tolerancia a fallos (ECC memory)

Fuente de poder Especificación técnica Redundancia

Garantía de fábrica

Proveedor y contacto Fecha de Vencimiento

Contrato de mantenimiento Proveedor y contacto Fecha de vencimiento




Otros

Recuperación del equipo Estrategia de recuperación {Detalle la generalidad de la estrategia a seguir para la recuperación} Recursos requeridos previo o durante el proceso de recuperación

ID Recurso Ubicación Responsable

Procedimientos para instalar y configurar el equipo de comunicación. Cuando aplique, incluya versiones de sistema operativo y parches


Procedimientos requeridos para validar la instalaci ón y configuración


Procedimientos de validación y sincronización con o tros equipos






Notas:

Resumen del Estado del Evento (PTC014)

En este formulario podrá documentar una bitácora de las actividades desarrolladas durante la contingencia y la recuperación de los servicios de TIC. (PTC011)




Resumen del Estado del Evento (PTC011)

Nombre del Incidente: __________________________________ Lugar:_______________________________________

Nombre de la persona que reporta: _________________________________________________________________________

Procedimiento aplicado

Resultado Estatus

Fecha Preparado:

Actividad: Fecha y Hora:


Plan de Continuidad TIC autor::




Evaluar el Estado del Equipo de TIC (PTC015)

La evaluación del estado del equipo de TIC se realizará posterior al evento de interrupción o desastre. Es importante obtener un entendimiento de en qué estado quedó el equipo para lo cual deberá completar la tabla adjunta. (PTC012)

Evaluar el Estado del Equipo de TIC - PTC015 Lugar:______________________

[-----------ESTADO----------]

Nombre Evento:__________________________

Equipo

Condición (*)

Tiempo Rescate

Comentarios

1. _______________________ ___________ _________ ______________________________

2. _______________________ ___________ _________ ______________________________

3. _______________________ ___________ _________ ______________________________

4. _______________________ ___________ _________ ______________________________ Legenda (*) Condición: ND - No Dañado DPU - Dañado, pero utilizable DR - Dañado, requiere rescate antes de usar D - Dañado, requiere reconstrucción


Plan de Continuidad TIC autor:: Legenda (*) Condición: ND - No Dañado DPU - Dañado, pero utilizable DR - Dañado, requiere rescate antes de usar D - Dañado, requiere reconstrucción Se muestra a continuación un ejemplo de cómo completar dicha tabla:

[-----------ESTADO----------]

Equipo

Condición (*) Tiempo Rescate

Comentarios

1. Servidor de Base de Datos DRU (dañado pero utilizable)

2 horas Equipo sufrió daño en tarjetas controladoras, mismas que deberán sustituirse vía contrato de mantenimiento correctivo. Refiérase a Procedimiento de Recuperación correspondiente




15. Anexo IV – Guía para el desarrollo de ensayos d el plan de continuidad en TIC 2. Introducción

Introducción

El propósito de ensayar el Plan, es asegurar la viabilidad y actualización del mismo. Un Plan que es ensayado regularmente permite identificar aspectos no cubiertos inicialmente, o bien, debilidades en el proceso de mantenimiento del mismo. Adicionalmente, todo ensayo debe ser considerado como una oportunidad para entrenar al personal, tanto en la forma de actuar ante la situación de emergencia como en los procedimientos de recuperación establecidos.

Ensayos del plan 3. Ensayos del Plan de Continuidad

Como parte del proceso de mejora continua al cual debe someterse todo Plan de Continuidad, la realización de ensayos1 es un pilar fundamental que la CCSS deberá desarrollar con el fin de garantizar la actualización y el mantenimiento de estos Planes. No ensaye para tener éxito. Ensaye para tener entendimiento. Todos los ensayos deben considerarse como exitosos si su objetivo es validar el plan, y las debilidades o los errores no cubiertos no se convierten en factores negativos para el Plan, de otra forma el ensayo habrá fracasado. Algunas de las recomendaciones a seguir para el desarrollo de los ensayos de un Plan de Continuidad en TI se listan a continuación: 1. Utilizar el documento PTC010 para el planeamiento de los ensayos a realizar. Este documento incorpora elementos que con su definición, establecerán un escenario claro y preciso para la realización de cada ensayo. Los escenarios sobre los cuales se puede desarrollar un ensayo pueden ser múltiples, desde problemas básicos con un respaldo de datos o un componente de un equipo de cómputo, hasta un evento de desastre que afecte la totalidad de las instalaciones de TIC. El escenario bajo el cual se hará el ensayo debe ser definido con anterioridad. El plan está preparado para reaccionar y dirigiar las acciones de recuperación en cualquiera de los casos descritos. 2. Garantizar la adecuada capacitación del personal en el entendimiento de la documentación del Plan de Continuidad, y de todo documento que esté relacionado con el tipo de ensayo (vea más adelante la sección Tipos de Ensayo) y el alcance del mismo. 3. Para la realización propia del ensayo, deberá documentar los procedimientos que seguirá para el mismo, para lo cual deberá considerar al menos lo siguiente: a. El detalle inicial del tipo de ensayo que se desea realizar. Para más detalle vea la sección Tipos de Ensayo. b. El objetivo que se busca con el desarrollo del ensayo.




c. Los procedimientos de recuperación que serán probados. Esto último implica establecer cuáles de los procedimientos descritos en el plan, serán considerados para realizar el ensayo. d. La responsabilidad del ensayo. Esto implica definir quién será responsable de velar por la adecuada realización del ensayo y de obtener al final, las conclusiones y los resultados del mismo. Esta responsabilidad puede recaer en el coordinador del plan de continuidad, en el responsable de TIC u otra persona asignada por uno de ellos. e. La planeación y la calendarización del ensayo, donde se indique qué día y horas se realizará el ensayo. Esto no aplica si se desea hacer un ensayo sorpresa. f. Las métricas de evaluación de los resultados, estas pueden variar dependiendo del tipo de ensayo que se desee realizar. Las métricas deberán ser definidas por el coordinador del plan de continuidad, estableciendo de qué forma se concluirá si los resultados del ensayo fueron o no adecuados. 4. Luego de la conclusión del ensayo, se deberán obtener las conclusiones al respecto de: a. Información que debiera ser corregida en el Plan de Continuidad por deficiencias o errores encontrados durante el ensayo; b. Información que debiera ampliarse para mejorar su claridad en el Plan al momento de ser utilizada; c. Información sobre elementos de riesgo que fueron identificados durante el ensayo, como puede ser personal no encontrado, documentación no identificada, etc.; d. Obtener finalmente conclusiones sobre si la documentación de los procedimientos definidos es práctica o si bien los procedimientos pueden eficientizarse para obtener mejores resultados considerando variables como tiempo, costo y esfuerzo. e. La documentación y revisión de todos los resultados generados durante el ensayo es trascendental para el proceso de mejora continua. Refiérase a la sección “Evaluación de los Ensayos” para mayor información. f. Los ensayos deben ser al menos una vez al año, según calendario

Directriz para ejecución de los ensayos del Plan Deberá establecerse una directriz en la cual se establezca que todos los medios necesarios para la realización de los ensayos del Plan de Continuidad de TI deberán facilitarse en el tiempo que sean requeridos. Ello permitirá la actualización de los procedimientos, así como la capacitación necesaria para el desempeño eficaz y eficiente de este plan.

Objetivos de los ensayos Los ensayos del plan tienen como objetivos principales los siguientes: - Incrementar la conciencia y el conocimiento en el plan; - Validar del plan;




- Actualizar y corregir el plan para que contemple los cambios en el ambiente del negocio y requerimientos de soporte; - Entrenar a los miembros de los equipos de recuperación, con el propósito de minimizar el tiempo de respuesta y de recuperación; - Verificar la disponibilidad de los datos y recursos críticos almacenados fuera de sitio; - Comunicar formalmente a la Alta Administración los resultados de los ensayos.

Coordinador de los ensayos Una persona deberá ser designada como el coordinador de los ensayos. En algunos casos, es conveniente seleccionar un coordinador diferente para cada uno, eso incrementa el entrenamiento de los líderes. No se debe olvidar que ese coordinador de los ensayos debe ser una persona familiarizada con el proceso del negocio, el plan y los sistemas de información utilizados.

Responsabilidades del CPC en los ensayos Es responsabilidad del Coordinador del Plan de Continuidad el planear y ejecutar los ensayos conjuntamente con el Coordinador de los mismos. Un factor de éxito para los ensayos es la obtención del respaldo de la Alta Administración (o Jefe de la locación). Ese respaldo debe asegurar la disponibilidad de los recursos necesarios para que los ensayos sean efectivos y provechosos. Las responsabilidades del coordinador de los ensayos incluyen, entre otras, las siguientes: - Determinar el tipo de ensayo a realizar. - Asegurar que el plan está actualizado permanentemente y antes de los ensayos. - Definir el alcance, objetivos, supuestos y escenario del ensayo. - Documentar todos los costos asociados con el desarrollo del ensayo. - Establecer la fecha del ensayo. - Planear y documentar actividades y reuniones, tanto previas como posteriores a los ensayos. - Coordinar y mantener una bitácora de todas las actividades antes, durante y después del ensayo.

Tipos de ensayos Para cumplir con los objetivos de los ensayos no es práctico, ni necesario, que todo en el plan sea cubierto en una única sesión. No obstante, es importante administrar los componentes críticos del mismo; y consecuentemente, los ensayos deben ser vistos como una serie eventos para los cuales se debe establecer un calendario que permita comparar tiempos estimados y actuales. Es recomendable, que en el alcance de los ensayos se defina las tareas y funciones que serán probadas. También se debe indicar lo que no será probado, con el fin de no crear falsas expectativas con respecto al ensayo a realizar. Todos los tipos de ensayo ayudan a capacitar al personal, a mantener a los empleados con un alto conocimiento y demostrar la efectividad de los planes de continuidad en TI. Por lo tanto, los ensayos no deben limitarse, a la utilización de las siguientes técnicas para demostrar la habilidad de recuperar los componentes críticos de la Plataforma.




Procedimientos de Recopilación Verificar que todos los registros vitales han sido identificados y que están protegidos fuera de sitio, además que esos registros son recopilados de forma organizada y con tiempos apropiados. Walk-Trough Independiente (en-sitio) Permitir a cada equipo la oportunidad para ejercitar sus procedimientos de recuperación de manera independiente, previa al ensayo conjunto, esto permite identificar áreas de mejora y actualizar el plan, así como ejercitar la habilidad de cada Líder de Equipo. Walk-Trough Combinado (en-sitio) Permitir a cada proceso de negocio la oportunidad de probar la habilidad de sus equipos en las acciones de recuperación como una unidad combinada, probando el trabajo de los procedimientos de recuperación documentados, con el fin de identificar áreas de mejora y actualizar el plan. Activación de los equipos de Recuperación La activación de los equipos confirma la disponibilidad de sus miembros, así como su habilidad para realizar responsabilidades asignadas de manera eficiente y a tiempo. Después de que los equipos son activados, el coordinador de los ensayos s debe asegurar que los equipos conocen sus responsabilidades, para ello se podría solicitar a cada uno de los equipos que discuta sus responsabilidades antes del ensayo con los otros miembros involucrados. Ensayos de Simulación Establecer escenarios para los ensayos ante un desastre, los cuales provean a los participantes con situaciones que podrían afectar como cada miembro de los equipos reaccionará. Los escenarios brindarán a la administración con una base para iniciar la activación de sus planes y efectuar la recuperación de los procesos de negocios de los cuales ellos son responsables.

Frecuencia de los ensayos Los ensayos deben ser realizados al menos una vez al año, o en su defecto de los cambios en el ambiente en las operaciones. No obstante, dependiendo del riesgo, es conveniente elaborar un calendario de ensayos más frecuente y riguroso. Es conveniente tener en cuenta que los resultados de los ensayos deben ser formalmente reportados. Además, en caso de que sea necesario, el Plan podría requerir ser actualizado, para lo cual el CPC debe actualizar un formulario “Mantenimiento del Plan” (PTC014) incluido en esta guía.

Calendario de ensayos El Coordinador del Plan de Continuidad deberá preparar un calendario de ensayos. Es recomendable que ese calendario este ligado con el Plan de Capacitación. Para elaborar el calendario de actividades se puede utilizar una matriz como la mostrada en el formulario “Matriz de Ensayos del Plan” (PTC010) incluida en esta guía, en la cual se coloca el tipo de ensayo a realizar y la fecha en que se llevará a cabo el mismo. Es conveniente que previo a la programación del ensayo, el CPC prepare el plan del mismo.




El formulario “Ensayo del Plan” (PTC013) de esta guía se utiliza para documentar tanto los objetivos, escenario, áreas a ser probadas, etc., así como los resultados de los ensayos.

Evaluación de los ensayos Una revisión posterior al ensayo debe ser realizada dentro de las dos semanas siguientes al mismo y todas las personas que participaron en él deben estar presentes para la revisión de los resultados. Un proceso de evaluación deberá responder, entre otras, a las interrogantes siguientes: ¿Se cumplieron los objetivos establecidos para el ensayo? ¿Se realizó el ensayo en el tiempo establecido? ¿Fue el ensayo elaborado y conceptualizado apropiadamente? ¿Cuáles partes del Plan fueron inadecuadas o no estaban actualizadas? ¿Puede el personal de los equipo de recuperación utilizar el plan de forma efectiva? ¿Fueron todas las interfaces críticas identificadas y documentadas? Después de la reunión de revisión del ensayo se deberán documentar los resultados de la misma. Para ello se utilizará la sección “Resultados” del formulario “Ensayo del Plan” (PTC013) incluido en esta guía. Los Líderes de los equipos serán responsables de comunicar los resultados del ensayo a todos los miembros de sus equipos, con el fin de mejorar el Plan a partir de los resultados. Adicionalmente, el coordinador del ensayo será responsable de lo siguiente: - Comunicar los resultados de los ensayos a la Administración. - Elaborar una lista de todos los inconvenientes identificados durante el ensayo y asignar a los miembros de equipos para que trabajen en ellos. - Brindar seguimiento a la resolución de esos problemas. Basado en los resultados de los ensayos, el Coordinador del Plan debe determinar si se debe realizar un ensayo de seguimiento. Si éste no es necesario, se debe seguir con el calendario de ensayos y proponer las áreas que deben ser probadas. Es recomendable que los objetivos de los ensayos de seguimiento estén limitados a aspectos específicos que no fueron exitosos durante el ensayo realizado anteriormente. De lo contrario, no se podría validar que se hayan resuelto los inconvenientes encontrados previamente. Luego de la ejecución del ensayo las situaciones u oportunidades de mejora al Plan deberán ser recolectadas y documentadas, y reportadas formalmente al administrador institucional de la continuidad. Como parte de la evaluación de resultados deberá incluir al menos lo siguiente: a) Una evaluación de los planes y procedimientos que fueron ejercitados. b) El tipo y la calidad de respuesta a las situaciones del escenario que fueron establecidas para el ensayo. c) Una evaluación de la cooperación y la respuesta recibida de terceros (si aplica) entre los que se cuentan por ejemplo proveedores y clientes. d) Una lista del personal que estuvo presente durante el ensayo. e) Una bitácora de actividades desarrolladas con la evaluación de tiempo previsto (el que espera que dure la actividad) y tiempo final de ejecución (el que duró realmente).




f) Un detalle de eventuales problemas que surgieran durante el ensayo. g) Finalmente agregue sus conclusiones sobre el desarrollo del ensayo.

Guía para el desarrollo de ensayos Esta sección describe las actividades administrativas requeridas para elaborar, coordinar y supervisar los ensayos del plan. De manera que estas actividades provean oportunidades de mejora para el Plan y al mismo tiempo que se vaya incrementando en el personal involucrado, la experiencia en responder a una contingencia. Para preparar y desarrollar el ensayo puede atender a las actividades siguientes: 1. Establezca los objetivos del ensayo a realizar. Incluya, al menos, lo siguiente: • ¿Pueden ser medidos? • ¿Cómo pueden ser evaluados? 2. Establezca el alcance del ensayo • ¿Cuáles áreas serán incluidas? • ¿Cuáles procedimientos, listas de chequeo y responsabilidades serán probadas? • ¿Cuáles excepciones, si hay, deben ser consideradas? 3. Desarrolle el escenario del ensayo. 4. En caso necesario, estime el tiempo total del ensayo en el sitio alterno. Considere el tiempo de desplazamiento del personal. 5. Revise la configuración del hardware en el sitio alterno para verificar compatibilidad. 6. Verifique el inventario de los archivos de respaldo mantenidos en el sitio de almacenamiento con el control que se tiene del mismo, con el objetivo de verificar los procedimientos de actualización de respaldos. 7. Seleccione al personal que participará en el ensayo e infórmelo. 8. Familiarice al personal con la logística del sitio-alterno. 9. Obtenga permiso del proveedor del software para usar los productos con licencia en el sitio alterno tanto en los ensayos como durante un posible desastre. 10. Obtenga y transporte los respaldos, formularios, suministros y documentación requerida para el ensayo. 11. Realice los arreglos de transporte, hospedaje y comidas para el equipo del ensayo. 12. Ejecute el ensayo. 13. Compare los resultados del ensayo con los resultados esperados y escriba un informe. 14. Corrija los errores detectados y actualice el documento del plan.




Matriz de ensayo del plan (PTC016) Calendario anual de ensayo Año: _______

Tipo de Ensayo

EN

E

FE

B

MA

R

AB

R

MA

Y

JUN

JUL

AG

O

SE

T

OC

T

NO

V

DIC

1-

2-

3-

4-

5-

6-

7-

8-




Ensayo del Plan (PTC017)

Tipo de Ensayo ___________________________Fecha/Hor a de Inicio_______________________

____________________________Fecha/Hora de Fin____ _____________________

Sitio de Ejecución _______________________Equipos _ ______________________________

Involucrados_____________________________

Objetivos

Criterios de Medición

Criterio Medio de validación Resultado

Tiempo de atención

Tiempo de Respuesta

Volumen de transacciones

Tiempo de espera

Áreas a ser probadas

Área / aplicativo Prueba/ transacción Resultado esp erado Resultado obtenido

Escenario

Resultados

Recomendaciones





Plan de Continuidad TIC autor:: 16. Anexo V – Mantenimiento del Plan (PTC018) Para la comunicación de las modificaciones al plan se debe utilizar este formulario.

Adicionalmente, es conveniente que se entregue el d ocumento en forma electrónica para

facilitar su incorporación al Plan.

Nombre Equipo: ____________________________________ ______________________________

Líder de Equipo: __________________________________ _______________________________

Fecha: ____________________ Hora: _________________ _

Justificación para la modificación:

_________________________________________________________________________________

_________________________________________________________________________________

_________________________________________________________________________________

Modificaciones solicitadas:

______________________________________________________________________________________

______________________________________________________________________________________

__________________________________________________________________________

Observaciones:

______________________________________________________________________________________

______________________________________________________________________________________

__________________________________________________________________________


Plan de Continuidad TIC aprob::




17. Anexo VI – Documento Procedimientos alternos de trabajo.

Introducción . Introducción

Los procedimientos alternos de trabajo son una herramienta para hacer más organizada y efectiva la ejecución de las tareas durante la recuperación de los sistemas de información que soportan un proceso o área funcional. Una contingencia puede generar mucha presión en el personal involucrado durante el proceso de recuperación y por lo tanto es importante que ellos estén provistos de guías para tomar decisiones oportunas durante estas situaciones. Adicionalmente, esas acciones se realizan más fácilmente cuando los individuos de la organización asumen un papel activo y responsable en el desarrollo de los procedimientos a seguir si un desastre ocurriera. Es conveniente recalcar que el personal y no el plan, será responsable de manejar los esfuerzos de recuperación, así que el involucramiento temprano de aquellos individuos con un mayor entendimiento de sus áreas de trabajo es conveniente para el desarrollo del plan. 2. Documentación de Procedimientos Alternos de Trab ajo

Evaluación de factibilidad para la documentación Como parte del desarrollo de un análisis de impacto en el negocio, se deberá incluir una solicitud de información a cada área o proceso del negocio en donde se determine la existencia o no de procedimientos alternos ya establecidos para el desarrollo en primera instancia de los procesos críticos y eventualmente luego, de procesos no críticos, según los niveles de criticidad establecidos por el mismo análisis de impacto en el negocio. En caso de existir dichos procedimientos alternos se deberá proceder a documentar los procedimientos o revisar y actualizar (cuando aplique) esos procedimientos. Se debe considerar que esos procedimientos alternos pueden lograrse a través de herramientas manuales (ej. formularios) o bien automatizadas (hojas electrónicas, procesador de palabras u otros sistemas de operación local), en las que se tenga dependencia de únicamente una computadora personal, eventualmente una línea de comunicación conmutada, y que podrían estar disponibles si así lo requiere el área o el proceso de negocio, sea esto en el sitio primario o en un sitio alterno. Cada área o proceso del negocio será responsable de determinar cuando se puede o no documentar un Procedimiento de este tipo. Como ejemplo, uno de los factores que influyen en esa decisión es, considerar si es posible mantener en el procedimiento alterno iguales o superiores controles, que los utilizados cuando se utilizan los sistemas de información normales. Dado el caso que la aplicación de los controles en un nivel igual o superior no pueda mantenerse, el área o proceso de negocio tendrá la potestad de eventualmente no desarrollar el Procedimiento y esperar a la recuperación de la plataforma de TIC. De otro modo, la documentación de los Procedimientos es responsabilidad de los responsables de cada área o proceso del negocio. Como esquema general para completar los formularios siga lo siguiente: 1. Aplique a cada área o proceso de negocio, el formulario descrito en el anexo 3.1 de este documento y determine la existencia de procedimientos alternos en las áreas o la posibilidad de realizar la documentación respectiva. 2. Determine un inventario de procesos de negocio para los cuales pueda documentarse un PAT.




3. Para cada proceso donde sea factible la documentación de un PAT, deberá completar el formulario incluido en el anexo 3.2 de este documento. 4. El usuario responsable del proceso de negocio deberá completar el formulario descrito desarrollando las actividades siguientes a. Completar la sección encabezado con los datos indicados. Para mayor detalle del significado de cada ítem de información refiérase a la sección 2.2 de este documento. b. Complete los datos de Unidad de Negocio, Procedimientos relacionados, Objetivos y Responsables. Para mayor detalle del significado de cada ítem de información refiérase a la sección 2.2 de este documento. c. Como Recursos Críticos se deberá documentar qué personal deberá estar presente para la ejecución del procedimiento, completando los datos de ubicación. Podría involucrarse personal externo (proveedores). Adicionalmente considere documentar en esta sección, qué equipos de oficina o comunicaciones requerirá para desarrollar el PAT, el nombre de formularios y cualquier otro recurso requerido para aplicar el documento. d. En la sección Detalle del Procedimiento, deberá documentar las acciones que el usuario deberá desarrollar como parte de la forma alterna para ejecutar el proceso en cuestión. Las acciones deberán documentarse en el mismo orden en el cual deberán ser ejecutadas. Adicionalmente complete en cada caso quién es el responsable (puesto) de ejecutar la acción y qué recursos de los descritos en la sección anterior, se requerirán para ejecutar la acción. e. Cuando se logran restaurar las operaciones de la plataforma de TI, todo lo que se había ejecutado fuera de los sistemas de información regulares, deberá de ingresarse para actualizar la información de la base de datos central. Por ese motivo, en la sección Actividades a desarrollar luego de la restauración de TIC, documente en orden de ejecución, las acciones que deberá realizar el usuario para alimentar la información en los sistemas y actualizar correctamente las bases de datos. f. Finalmente en la sección de notas o comentarios documente cualquier situación adicional que pueda o debe considerarse como parte de la ejecución del PAT. Puede considerar supuestos, restricciones, etc. En el anexo 3.1 se incluye un modelo del formulario que se utilizará para evaluar en cada área o proceso de negocio, la disponibilidad de los procedimientos alternos. Otra información que se puede obtener a partir de dicho formulario es la siguiente: • Descripción de los procedimientos alternos que estén documentados; • Tiempo que dispara la utilización de dicha documentación; y, • Tiempo durante el cual el área o proceso puede operar con los procedimientos.

Descripción del formulario para documentación de PA T Para la definición de un procedimiento alterno se debe considerar que será utilizado en el caso del peor escenario, cuando la operación de la plataforma tecnológica sea interrumpida por un




período superior al cual el proceso de negocio pueda soportar para su interrupción. La descripción de cada uno de los campos requeridos para completar el Procedimiento se describen a continuación: Código de Procedimiento Código de identificación asociado con el proceso del negocio que está siendo documentado. Los códigos de referencia tienen el siguiente formato, PAT-XX-YY, donde: XX indica las siglas del proceso de negocio, YY es un número secuencial que diferencia componentes (procedimientos) de un mismo proceso. Fecha de emisión Fecha en que se elaboró el documento o se realizó la última actualización. Fecha de aprobación Fecha en que se aprobó el documento Versión Aunque la fecha del documento puede ser utilizada como base para un control de versiones es conveniente la utilización de un sistema de numeración que permite incluir versiones en borrador. La numeración de las versiones se hará de la siguiente forma “v.rb ”, donde • v = número de versión, iniciando en 1; • r = nivel de revisión, iniciando en 0 (dentro de cada versión); • b = letra para indicar la secuencia del borrador dentro de la misma revisión, iniciando en A. Por ejemplo, el número de versión 1.1C indica que se trata del tercer borrador de la versión 1.1. Para la primer vez que se documente el procedimiento alterno debe utilizarse el número de versión 1.0A. Escrito por Nombre de la persona responsable de la documentación del procedimiento. Aprobado por Nombre de la persona responsable de aprobar la información contemplada en el procedimiento. Unidad de negocio Nombre del área funcional para la cual se está documentando el Procedimiento Alterno de Trabajo. Procedimientos relacionados Nombre de otros Procedimientos Alternos o documentos relacionados con el actual.




Objetivos Indicar el objetivo del procedimiento. Por ejemplo, ante un evento contingente que afecte los sistemas de información que soportan el proceso de planillas, el objetivo de un procedimiento alterno podría ser “Garantizar el pago oportuno de la planilla de los empleados.” Responsables ¿Quién(es) será(n) responsable(s) ante la organización de dirigir, controlar y ejecutar las actividades necesarias para alcanzar los objetivos definidos? Recursos críticos ¿Qué recursos se necesitan para realizar el procedimiento alterno? De ser necesario indique: ¿en qué momento serán requeridos? Los recursos podrían incluir personal interno / externo, equipo de cómputo y oficina, etc. Detalle del procedimiento ¿Qué acciones se deben ejecutar para cumplir con los objetivos? Las acciones deben ser tan simples, concisas y puntuales como sea posible, de manera que sean claras y fáciles de interpretar. Se aconseja el formato de “Lista de Chequeo”. Otros Cualquier otro elemento que pueda formar parte del procedimiento Actividades a desarrollar luego de la restauración de TIC ¿Qué acciones se deberán ejecutar luego de la restauración de los servicios de tecnología de información y comunicaciones para actualizar en los sistemas la información recopilada con los Procedimientos Alternos durante el tiempo que estuvieron fuera los servicios de TIC? Notas y comentarios Indique en esta sección del Procedimiento cualquier aspecto que no esté contemplado en alguna otra sección y que se considere relevante para su ejecución exitosa. Por ejemplo, los supuestos para que el procedimiento funcione, cuándo se requieren los recursos, la necesidad de definir formatos especiales en papel o MS-Office para su uso durante la recuperación, etc.

NOTAS:

• No combine procedimientos. Se debe utilizar un formulario para documentar cada actividad que

requiera un procedimiento alterno de trabajo.

• Los procedimientos deben describir la forma de trabajar mientras no se disponga de los servicios de

Tecnología de Información (correo electrónico, Internet, sistemas de información, etc.)

• No se debe indicar la forma en que se realiza la actividad o el proceso. Hay que recordar que no se están

documentando los flujos de los procesos.

Procedimiento alterno de trabajo encuesta

PROCEDIMIENTOS ALTERNOS DE TRABAJO DISPONIBLES Los procedimientos alternos son aquellos procesos manuales o semiautomáticos que podrían reemplazar, parcial o totalmente, el trabajo realizado a través de los sistemas de información.

A.1

¿Dispone su Proceso de Negocio de algún procedimiento alternativo para trabajar en caso de una interrupción? Si su respuesta es NO, pase a la pregunta A.2. Si su respuesta es SI, pase a la pregunta A.3.

A.2

¿Es factible para su Procesos de Negocio documentar procedimientos alternos de trabajo? Describa, en los espacios correspondientes, para qué procesos del negocio sería factible desarrollar procedimientos manuales Procesos de Negocio

A.3

¿Están dichos procedimientos formalmente documentados? en caso afirmativo, adjunte formulario Describa, en los espacios correspondientes, en qué consiste el procedimiento alterno, así como los supuestos en que se basan sus procedimientos.

Procedimiento Alterno Supuestos

A.4 Indique la cantidad de tiempo requerido para comenzar a utilizar dichos procedimientos alternos en el momento de la contingecia

A.5 Indique por cuánto tiempo podría el Proceso de Negocio continuar utilizando ese procedimiento alterno en el momento de la contingencia



A.6

¿Qué porcentaje de la carga de trabajo normal del Proceso de Negocios podría ser manejada por esta alternativa?

A.7

¿Cuándo fue la última vez que estos procedimientos alternos fueron utilizados o probados?

A.8

¿Cuándo fue la última vez que el personal fue entrenado en el uso de estos procedimientos alternos? A.9 Si bajo condiciones normales de trabajo (con sistemas de información disponibles) su proceso de negocios tiene trabajo pendiente por realizar, entonces brinde una descripción de ese trabajo que está pendiente, incluya entre otros los motivos por los cuales lo está, los periodos en que normalmente se presenta dicha situación (meses/semanas/día) y el tiempo que se requiere para eliminar ese trabajo pendiente.

Fecha de

emisión:

Procedimiento alterno de trabajo (PTC019)

Código de

Procedimiento

PAT-XX-YY Fecha de

aprobación:

Escrito por: {nombre} Aprobado por: {nombre} Versión {v.rb}

Página

80 de x

Unidad de Negocio

Procedimientos

relacionados

Objetivos

Responsables

Recursos críticos Personal (Administrativos, funcionales, otros):

Nombre Puesto o Empresa Teléfono o Correo-e

Equipo de comunicaciones (teléfono, fax, radios, etc.):

Equipo de oficina (impresoras, máquinas de escribir, etc.):

Formularios y documentos:

Otros recursos:

Detalle del procedimiento

Acciones (en orden secuencial) Responsable Recursos

Otros

Actividades a desarrollar

luego de la restauración

de TIC


Notas y comentarios




Fecha de

emisión:

01/04/2007

Puede incluir acá un

logo Ejemplo. Procedimiento

alterno de trabajo

Atención al cliente

Código de

Procedimiento

PAT-AC-01

Fecha de

aprobación:

11/04/2007

Escrito por: Leonardo Fernandez M Aprobado por: Rosario Castro T. Versión 1.0

Página

81 de 1

Unidad de Negocio Atención al cliente

Procedimientos

relacionados

Ninguno

Objetivos

Mantener la atención a los cliente para el pago de obligaciones patronales

Responsables

Leonardo Fernandez M.

Recursos críticos Personal (Administrativos, funcionales, otros):

Nombre Puesto o Empresa Teléfono o Correo-e

Rosario Castro R. Jefe de Área 284-7022

Leonardo Fernandez Plataforma 295-2401

Equipo de comunicaciones (teléfono, fax, radios, etc.):

Dos teléfonos, un fax

Equipo de oficina (impresoras, máquinas de escribir, etc.):

Una impresora

Formularios y documentos:

Formulario recibo de dinero por concepto de pago de planillas

Listado de pendiente de pago por patrono

Otros recursos:

Una computadora y sistema manual para emisión de recibos

Detalle del procedimiento


Recibir al cliente Leonardo F.M. No aplica

Confirmar pendiente de pago en listado Leonardo F.M. Listado de pendiente

Recibir el pago del patrono Cajero Recibos de dinero

Entregar recibo al patrono Cajero No aplica

Otros No hay

Actividades a desarrollar

luego de la restauración

de TIC


Ingresar los recibos de dinero en el

sistema

Cajero Recibos de dinero y

Sicere en operación

Notas y comentarios

No hay.




18. Anexo VII – Escalacion de eventos (PTC020)

Protocolo de Escalación de eventos(PTC020)

{Nombre del Lugar}

Información General

Objetivos del protocolo {Documente cuál es el objetivo de este documento}

Estatuto de Declaratoria: ____________________________________________________________________________________ ___________________________________________________________________________________

Criterios de declaratoria del Evento : Autorizados a declarar el evento Identificación de Potenciales problemas Definir cuando y como puede el

problema ser escalado

Árbol de listas de contactos Primer Nivel de contacto Nombre Contacto lugar Equipo a Activar Medio de notificación

Segundo Nivel de contacto Nombre Contacto lugar Equipo a Activar Medio de notificación

Tercer Nivel de contacto Nombre Contacto lugar Equipo a Activar Medio de notificación

Nota: El líder definirá el medio en que será notificado a los diferentes contactos, para esto el contacto podrá documentar la notificación en el formulario Resumen del Estado del Evento (PTC011).






19. Anexo VIII – Plan de Capacitacion (PTC021) Para esto se debe considerar el plan de ensayos según el formulario (PTC010) incluida en esta guía. Para esto se sugiere los siguientes aspectos:

• Las presentaciones podrían incluir temas tales como: o Los componentes del plan de continuidad, o Porqué es importante el plan de continuidad, o Lideres y coordinadores, o Dónde el plan de continuidad puede tener lugar, o Presentación del plan de ensayos, o Cómo el plan es activado.

• En lo referente al tipo de audiencias estos podrían ser Gerencial, Regional, Local, Miembros del equipo de

recuperación, nuevos empleados, etc,

• En temas de concientización, se podrían utilizar videos, noticias, póster, Memo de la administración, artículos promocionales. Etc.

• En cuanto a temas de concientización es importante revisar desastres recientes y lecciones aprendidas, por

medio de forum de discusión, artículos en la intranet, etc.

Calendario Capacitación - PTC021 Año:__________

Tipo capacitación

audiencia Capacitador Tiempo frecuencia Lugar Presupuesto

1-

2-

3-

4-






20. Anexo IXX – Presupuesto de equipo para conting encias

Para poder atender los eventos en el menor tiempo de respuesta se requiere mantener una serie de equipos asignados de acuerdo a los servicios críticos identificados en la matriz de Tiempos Máximos de interrupción (PTC004).

Presupuesto de Equipo para Contingencias (PTC022)

Equipo Sistemas de

Apoyo Cta gastos Ubicación

Proveedor Mantenimiento Justificación


Plan de Continuidad TIC Aprob:: Firma:

21. Anexo XX - Abreviaturas Se detalla a continuación algunas abreviaturas utilizadas en este documento y las guías para elaboración del Plan de Continuidad de TI

BCP Planeamiento de Continuidad del Negocio (Business Continuity Planning)

BIA Análisis de Impacto en el Negocio (Business Impact Analysis)

COE Centro de Operaciones de Emergencias

CPC Coordinador del Plan de Continuidad

DRP Planeamiento de Recuperación ante desastres (Disaster Recovery Planning)

EATI Equipo Administrador de Tecnologías de Información

EA Equipo de Aplicaciones

EC Equipo de Comunicaciones

EO Equipo de Operaciones

ITIL Administración de Servicios de TI (Information Technology Infrastructure Library)

PCTIC Plan de Continuidad en Tecnología de Información y Comunicaciones

RA Análisis de Riesgos (Risk Analisys)

TIC Tecnologías de Información y Telecomunicaciones

TMI Tiempo máximo de interrupción.

TIC-GCN-0001-Guia Para Elaboracion de Planes de Continui

Documents

Transcript of TIC-GCN-0001-Guia Para Elaboracion de Planes de Continui