10 errores más comunes al definir, implementar y ejecutar un DRP ( primera parte)

 

Es en las áreas de Tecnologías de Información y Comunicaciones (ICT por sus siglas en ingles Information and Communication Technologies) donde se gestionan los procesos de definición, diseño, implementación y actualización de un Plan de Recuperación Tecnológica en casos de Desastres (Disaster Recovery Plan), identificando los administradores/equipos, responsables y gestores de riesgos que deben estar involucrados para establecer los elementos o activos internos-externos, forma de comunicación con los grupos participantes, la responsabilidad y forma de actuar de cada uno de los elementos que deben solucionar o mitigar el incidente que afectará la entrega de los productos o servicios de la organización.

El DRP debe considerar los impactos potenciales en cada horizonte, en caso de un siniestro, entender los riesgos inmersos de forma integrada, documentar los procedimientos / protocolos de contingencia y minimizar los problemas para obtener la continuidad de sus servicios por la presencia de fallas o limitaciones en su infraestructura tecnológica o debido a eventos externos, estableciendo, documentando, ejecutando y probando actividades como:

o Establecer el Impacto en la Continuidad de las Operaciones (BIA) o Definición de Escenarios de Contingencia y Estrategias
o Identificación de Procesos Críticos con Prioridades
o Clasificación de Factores de Riesgo

o Cambiar enfoque del plan hacia SCP
o Cumplimiento consistente de las Métricas de Contingencia
o Diseño de Estrategias de Continuidad con Proveedores, ante resultados del VIA o Documentación de Flujos de Procedimientos / Protocolos de contingencia
o Probar la Estructura de Respuesta para Contingencia / Continuidad / Resiliencia

10 errores más comunes al definir, implementar y ejecutar un DRP

Error 1: El Plan no está alineado al Apetito de Riesgo.

  • En las organizaciones el apetito de riesgo es la cantidad y tipo de riesgo que están dispuestas a asumir en la búsqueda de sus objetivos. Un requerimiento importante en este punto es alinear los riesgos corporativos y del portafolio de proyectos al entorno actual del sector respectivo.
  • Al ser responsabilidad de ICT definir e implementar los planes DRP, estos solamente son analizados desde el punto de vista tecnológico, y no desde las necesidades de continuidad operativa, Legal, Auditoria, Viabilidad Financiera, Talento Humano, Gestión de Riesgo, por mencionar las más importantes
  • El plan DRP debe ser firmado por la Alta Dirección para la aceptación del apetito de riesgo establecido, sin esta variable se puede tener inversiones cuantiosas en facilidades alternas que no son requeridas dado el riesgo a ser aceptado por la empresa
  • La responsabilidad primaria de la eficiencia y protección del Plan DRP es del CEO Error2: Noseaseguraqueselogrenlosrequerimientostécnicosydenegociosalejecutar

el DRP para obtener como resultado el regreso a operación mejorada.

• En la parte de requerimientos técnicos, el plan DRP debe de ayudar a:
o Aumentar la eficiencia operacional de los procesos
o Optimizar la diversidad de infraestructuras: Multiplataforma, Nube, Hibrido, Movilidad,

Multicanales
o Identificar puntos únicos de falla en la cadena de suministro de sus proveedores críticos para

una mejor Adaptación, Recuperación, Transformación y Sustentabilidad
o Facilidades y Funcionalidad requerida en cada área
o Protocolos de respuesta y escalación basados en capacidades reales
o Medición capacidades de respuesta, de acuerdo a necesidades del negocio o Mapeo dinámico de Riesgos, Impactos y Requerimientos del negocio
o Asegurar la recuperación y confidencialidad de las estrategias
o Cumplir marcos regulatorios y necesidades de clientes (mejorar experiencia) o Limitar impactos en ITC con lecciones aprendidas

Error 3: El DRP no está 100 % documentada, actualizada y/o vigente.

  • Reflejar todos los cambios no planeados y organizacionales
  • Auditar el historial de los registros de pruebas, cambios y su justificación
  • Establecer una clara definición de roles y responsabilidades
  • Documentar pruebas buscando solucionar vulnerabilidades y no solo reportar excelencia en la ejecución de simulacros
  • Llevar a cabo sesiones de revisión de Postcontingencia para evaluar control de daños, manejo de alertas tempranas, efectividad de respuesta, riesgos emergentes, protocolos de actuación para actualizar el DRP
  • Aumentar el sentido de propiedad y compromiso en los equipos de respuesta
  • Automatización incluyente en procedimientos y protocolos
  • Utilizar capacidades de contingencia en la nube
  • Establecer el apoyo que se requiere de los usuarios / proveedores para pruebas,soporte “antes, durante y después” del posible incidente disruptivo.
  • Evitar áreas grises de responsabilidad entre ITC y las áreas del negocio.
  • Optimizar procesos de Failover, Failback y Telecomunicaciones.
  • Diagramas detallados de carga de trabajo centrada y arquitectura de recuperación.
  • Probar disponibilidad y acceso de Centros de Soporte de Redes (NOC), Centro de Crisis, Centro de Comando, Centro de Incidentes, Centro Alterno de Cómputo y Centros alternos de operación de usuarios con facilidades virtualizadas.

Ponte en contacto con nosotros para comenzar a diseñar el plan que se ajuste a las necesidades de tu negocio.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *