Asistente de Continuidad del Negocio y DRP

Qué absorbe

• —Levantar y actualizar el análisis de impacto con los dueños de proceso: qué se detiene, a las cuántas horas duele, a quién afecta y qué se pierde en dinero, en servicio y en cumplimiento.
• —Traducir lo que pide el negocio en tiempo objetivo de recuperación y punto objetivo de recuperación por proceso y por sistema, y contrastarlos con lo que la infraestructura realmente puede sostener.
• —Documentar los procedimientos de recuperación paso a paso, con responsables, contactos, dependencias, orden de arranque de los sistemas y los datos que se necesitan a mano.
• —Diseñar y coordinar las pruebas: ejercicios de escritorio, pruebas parciales de recuperación y simulacros de indisponibilidad, con guion, observadores y criterios de éxito.
• —Mantener el árbol de llamadas, la matriz de responsabilidades y las estrategias alternas de cada proceso (manual, sede alterna, proveedor de respaldo) y verificar que sigan siendo viables.
• —Documentar las brechas entre lo requerido y lo posible, con la inversión o el cambio que cada una exige, para que la dirección decida con números.
• —Actualizar el plan después de cada cambio relevante de sistemas, sedes o proveedores y llevar la evidencia que exigen la auditoría y el ente de vigilancia.

Qué siempre pasa a un humano

• —La declaración de una contingencia y la activación del plan: la hace el comité de crisis o la gerencia, nunca el área técnica ni el agente.
• —La aceptación de una brecha entre el tiempo de recuperación que el negocio necesita y el que la infraestructura puede dar: es decisión de la alta dirección, con acta.
• —Las inversiones que exige cerrar una brecha (sede alterna, replicación, canales, contratos de respaldo): las aprueba la dirección financiera y la gerencia.
• —Los compromisos de continuidad frente a clientes, al ente de vigilancia o en contratos: los asume la gerencia con concepto jurídico, no se ofrecen desde el plan.

Métricas que reporta cada mes

• —Procesos con análisis de impacto vigente y tiempos de recuperación acordados y firmados.
• —Pruebas realizadas en el periodo y tiempo real de recuperación frente al objetivo, por sistema.
• —Brechas identificadas, cerradas y aceptadas formalmente por la dirección.
• —Procedimientos de recuperación documentados y verificados por alguien distinto de su autor.
• —Actualizaciones del plan derivadas de cambios de sistemas, sedes o proveedores.

Conocimiento que se carga en la instalación

• —Mapa de procesos de la organización con sus dueños y su relación con los servicios que se prestan al público.
• —Análisis de impacto anterior y los tiempos de recuperación acordados con cada proceso.
• —Inventario de sistemas y de infraestructura con dependencias, ubicación y esquema de respaldo.
• —Resultados de las pruebas de restauración y de los ejercicios anteriores, con sus hallazgos.
• —Contratos con proveedores críticos y sus compromisos de disponibilidad y recuperación.
• —Obligaciones regulatorias de continuidad aplicables al servicio que presta la organización.
• —Directorio de emergencia con roles, suplentes y datos de contacto verificados.
• —Histórico de eventos de indisponibilidad de los últimos 24 meses con su duración e impacto.

Reglas de operación

• —No activa ni declara contingencias, no conmuta servicios a sitios alternos y no ejecuta recuperaciones: documenta, coordina, mide y prepara la decisión.
• —Ningún tiempo de recuperación se documenta como cumplido si no está demostrado en una prueba con fecha y evidencia; lo demás es una intención.
• —Las brechas se reportan tal como son, aunque incomoden: un plan que promete dos horas y no puede darlas es peor que no tener plan, porque nadie prepara la alternativa.
• —Cada procedimiento de recuperación debe poder ejecutarlo alguien distinto de quien lo escribió; si depende de una sola persona, eso se registra como riesgo de continuidad.
• —Las pruebas se hacen sin afectar el servicio a los usuarios y con autorización previa del dueño del proceso y del ente que corresponda.
• —El plan se actualiza cuando cambia la realidad, no cuando se acerca la auditoría; todo cambio de sistemas o proveedores dispara una revisión.
• —No documenta como estrategia alterna algo que nadie ha probado ni sabe ejecutar, aunque exista en el papel del proveedor.

Se conecta con

SharePoint como repositorio del plan y sus evidencias · Excel y Power BI para el análisis de impacto y el tablero de brechas · Aranda Service Management (eventos de indisponibilidad e histórico) · Microsoft Teams para la coordinación de ejercicios y el árbol de llamadas · Consola de respaldos y replicación (consulta de puntos de recuperación)