[vc_row][vc_column][vc_column_text]
Aunque no hay una estadística clara y sustentada, se calcula que alrededor de la mitad de las empresas no tienen un DRP. La otra mitad tiene uno, pero pocos apostarían su trabajo a que funcionará.
En 2018 la ONU (Organización de las Naciones Unidas) colocó a México en el top 10 de países de América con más afectaciones por desastres naturales. Y no solo eso, según la revista expansión nuestro país es el segundo en el mundo con más ataques de ransomeware en el Mundo entero.
Pero no se trata solo de hacer backup de nuestra información, de la imagen del servidor, o de documentar el BIA y todos los elementos del Business Continuity Plan. El asunto de la recuperación de negocio es sistémico y requiere de todos los componentes funcionando al cien.
En nuestra experiencia de más de 18 años en la industria de Continuidad de Negocio, hemos visto empresas que tenían un DRP, pero este no funcionó en el momento de la verdad: en una contingencia. Las principales y más comunes razones fueron:
- Falta de Pruebas
Es la obvia. Todos los expertos concuerdan en esto: un plan que no se prueba es un o que fallará. Pero siendo más profundos en el análisis, incluso probando, podría fallarse si no se hacen pruebas de manera constante, metodológica y con el alcance correcto. Una manera correcta de probar es en base a escenarios, por lo menos una vez por mes y, eventualmente, en ejercicios que incluyan a todos los participantes en un sentido práctico. Es decir, hacer el checksum de la copia del ERP en la nube no prueba nada hasta que el contador pueda volver a hacer facturas en el DRP.
- Insuficiencia de alcance
Por un lado está el alcance de BIA, donde nos dirán de forma demostrable cuáles son los procesos críticos alcance del DRP. La falla en DRP, refiriéndose al alcance, normalmente no está ahí, más bien está en los recursos que se le asignan. El DRP no debe ser una copia de la infraestructura principal, pero tampoco puede ser el repositorio de desperdicios: Me refiero al servidor modelo 2004 con 4 Mb en RAM que debía correr SAP o a las posiciones alternas en el comedor de la sucursal de Puebla. La infraestructura, toda, debe ser suficiente y eficaz para soportar la operación de la empresa durante un periodo más largo que las pruebas.
- Falta de mantenimiento
Probablemente acabas de regresar a la lectura después de revisar la fecha de actualización de tu DRP. El Ing. Vasquez ya no está a cargo de los servidores, de hecho ya no está en la compañía y localizarlo durante una contingencia al celular que tienes registrado no servirá de nada. Dar mantenimiento al DRP implica información actualizada en muchos rubros, desde los eminentemente tecnológicos como passwords o códigos de activación, hasta otros relacionados a difusión, contacto, cadena de suministro, etcétera.
- EL DRP tiene los mismos riesgos que la instalación principal
Muchas empresas tuvieron la idea de colocar su DRP en su propio entorno. El CFO está muy contento porque se aprovecha la infraestructura de TI asignada a sandbox de calidad. La buena noticia es que las pruebas han funcionado y todos están tan felices como el CFO porque no tienen que ir a un sitio alterno lejano. ¡Están a unas cuadras de su oficina principal! La mala noticia es que comparten los mismos riesgos. Primero los internos, los relacionados a sí mismos como huelgas o cierres de sucursales. Después, los de impacto masivo como un temblor o un ataque de ransomware a toda la instalación tecnológica.
La contingencia llegará, tarde o temprano, con algún tipo de amenaza conocida o desconocida. El DRP debe estar listo, en todo momento, para mantener a tu empresa funcionando el tiempo suficiente y con el servicio adecuado para no desaparecer. Es momento de asegurarte que tu DRP no fallará.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_single_image image=”790″ img_size=”full” alignment=”center”][/vc_column][/vc_row]
