El Instituto Nacional de Estadística e Informática (INEI), en el marco de Promoción y Difusión de las Nuevas Tecnologías de Información, pone a disposición de las entidades públicas, privadas, estudiantes y público en general, la publicación titulada: Guía Práctica para el Desarrollo de Planes de Contingencia de Sistemas de Información.
Tabla de Contenido
La presente publicación forma parte de la colección Seguridad Informática. Hace una breve introducción a los Sistemas de Información que incluye: La metodología práctica para el desarrollo de planes de contingencia de los sistemas de información que comprende: la identificación de riesgos, Calificación de la probabilidad de que ocurra un riesgo, Evaluación del impacto en los procesos críticos y la creación de estrategias de contingencias.
Los Planes de Contingencias le permitirán mantener la continuidad de sus sistemas de información frente a eventos críticos, de su entidad y minimizar el impacto negativo sobre la misma, sus empleados y usuarios. Deben ser parte integral de su organización y servir para evitar interrupciones, estar preparado para fallas potenciales y guiar hacia una solución.
El INEI realiza con esta publicación un aporte muy especial para todos los sectores de nuestro país, para garantizar en todo momento la continuidad de los Sistemas de Información, por ello pone a disposición la presente publicación, esperando una vez más contribuir en el desarrollo de la Sociedad de la Información.
Gilberto Moncada Vigo
Jefe
Instituto Nacional de Estadística Informática
Contenido
Capítulo I: Definiciones y Alcances
- ¿Qué es un Sistema de Información?
- ¿Qué es un Plan de Contingencias?
- Objetivos del Plan de Contingencia
- Aspectos Generales de la Seguridad de la Información
- Seguridad Integral de la Información
Capítulo II: Fases de la Metodología Para el Desarrollo de un Plan de Contingencia de los Sistemas de Información
- Planificación
- Identificación de Riesgos
- Identificación de Soluciones
- Estrategias
- Documentación del Proceso
- Realización de Pruebas y Validación
- Implementación
- Monitoreo
Capítulo III: Visión Práctica para realizar un Plan de Contingencia de los Sistemas de Información
- Análisis y Selección de las Operaciones Críticas
- Identificación de Procesos en cada Operación
- Listar los Recursos Utilizados para las Operaciones
- Especificación de Escenarios en los cuales puede Ocurrir los problemas
- Determinar y Detallar las Medidas Preventivas
- Formación y Funciones de los Grupos de Trabajo
- Desarrollo de los Planes de Acción
- Preparación de la Lista de Personas y Organizaciones para comunicarse en Caso de Emergencia
- Pruebas y Monitoreo
Capítulo IV. Prueba del Plan de Contingencia
- Introducción
- Objetivos
- Procedimientos Recomendados para las Pruebas del Plan de Contingencias
- Métodos para Realizar Pruebas de Planes de Contingencia
- Preparación Pre Prueba
- Comprobación de Plan de Contingencias
- Mantenimiento de Plan de Contingencias y Revisiones
- Entorno de las Pruebas del Plan de Contingencias
Cómo usar esta guía en la práctica
El orden de la guía es el orden del trabajo. Primero se definen las operaciones críticas, porque no todo pesa igual: un sistema que se puede detener un día no exige la misma respuesta que uno cuya caída detiene la atención al público o la operación completa. Después se listan, para cada operación, sus procesos y los recursos que usa, personas, aplicaciones, datos, hardware, red y energía, y se describen los escenarios en los que puede fallar cada uno. Solo con ese mapa tiene sentido calificar la probabilidad de cada riesgo, evaluar su impacto y elegir estrategias: prevenir, contar con un procedimiento manual, tener un recurso alternativo o aceptar un riesgo menor con los ojos abiertos.
El plan también necesita nombres, no solo procedimientos. La guía pide formar los grupos de trabajo, desarrollar los planes de acción y preparar la lista de personas y organizaciones para comunicarse en caso de emergencia. En una crisis real, la diferencia entre un plan que funciona y uno que queda en papel suele ser esa lista: quién decide, quién ejecuta, a quién se avisa y por qué canal, antes de que falle algo.
Un plan que no se prueba no es un plan
La guía dedica su último capítulo a probar el plan, y con razón: un procedimiento sin probar es una suposición. Probarlo significa recorrerlo con los responsables, simular un escenario concreto, por ejemplo la caída de un servidor crítico o la pérdida de conectividad, anotar dónde se traba, corregir el plan y volver a probarlo. Cada prueba debe dejar constancia de qué se probó, qué falló y qué cambió, y el plan debe revisarse cada vez que cambian los sistemas, los responsables o los recursos. Un plan guardado y sin revisar envejece al mismo ritmo que la infraestructura que describe.
Dos complementos actuales, coherentes con la misma lógica, son las copias de seguridad y su restauración probada: una copia que nunca se restauró en prueba no es una garantía, y un plan que depende de un solo proveedor, una sola sede o una sola persona clave tiene un punto único de falla que conviene identificar antes de la emergencia.
Nota sobre la descarga: al verificarla en octubre de 2026, el enlace del PDF no respondió. Se deja tal como se publicó, como registro de la fuente citada, y la publicación puede buscarse por su título en el sitio del INEI.
