Puntos A Considerar En La Implementación De Un Plan De Recuperación De Desastres

Puntos a verificar en la implementación de un Plan de Recuperación de desastres

Como sucede en casi todos los temas, en la implementación y seguimiento de un plan de recuperación en caso de desastres (DRP) existen aspectos que los manuales no mencionan y que de no tomarse en cuenta, pueden provocar riesgosas fallas al momento de necesitar ponerlo en práctica.

¿Puede alguien presumir que ha llevado a la práctica un Plan de Recuperación en Caso de Desastres (DRP) sin contratiempos? Lo más probable es que no. La diferencia es que algunas empresas han tenido problemas menores y otras han sufrido fallas importantes que les han impedido, incluso, arrancar el plan en el momento necesario.

Involucrados en este tipo de fallas mayores hay muchos: instituciones bancarias, empresas manufactureras, retails, farmacéuticas, y no de importancia menor, en muchos casos se trata de los principales jugadores de estos sectores.

Por supuesto, casi ninguna empresa está dispuesta a exponer públicamente que falló en su DRP y menos a hablar de cuáles fueron en concreto los errores cometidos. Pero se sabe de casos como el de una gran compañía nacional de manufactura de bebidas que no documento punto a punto los procesos de su plan de contingencia y cuando se enfrentó a un siniestro, simplemente no lo pudo echar a andar.

En este caso en particular, el problema fue que los procesos estaban descritos en forma muy general, el DRP decía, por ejemplo, levantar el sistema X, pero no se documentó cómo hacer eso paso a paso. Así que en plena contingencia, el equipo de respuesta enfrentó serias dificultades para llevar el manual a la práctica.

Otro caso fue el de un conocido retail, que por falta de experiencia en su equipo interno tardó más de cinco años en implementar su DRP. Finalmente la empresa se dio cuenta que necesita asesoría externa, pero para entonces ya habían arriesgado bastante tiempo la operación del negocio.

La lista de ejemplos puede seguir, pero en resumen y como una forma de ofrecer una guía a los lectores respecto a lo que no dicen los manuales de DRP, he aquí lo que puede bautizarse como las lecciones aprendidas en diferentes implementaciones de un plan de contingencia.

1.- Cada quien debe poner su parte. Lo primero que se debe tener muy en cuenta en esto de desarrollar e implementar un DRP es sí se está en sincronía con la alta directiva respecto a este tema y si se van a cubrir de forma adecuada las necesidades del negocio.

“Primero se debe definir qué entienden los responsables de la estrategia de contingencia por DRP y qué entienden los directivos de la organización. Ese es el primero dolor de cabeza, porque, muchas veces, se tiene la equivocada idea de que esto es un problema exclusivo del área de informática”, comenta Méndez.

Pero para que informática sepa cuál pie pone primero para levantarse, continúa, la alta directiva debe ayudarle a definir qué sustenta a la empresa. “Si informática no sabe cual es el corazón del negocio, no sabrá qué levantar primero. Los directivos deben ayudarle a determinar cuál es la infraestructura y los procesos que requieren recuperarse primero y en qué tiempo, para minimizar las pérdidas. Informática lo que pone es el cómo se hace la recuperación.

2.- Hay que darle al plan “el mantenimiento adecuado”. Muchas organizaciones, asegura Alejandro Cerezo, de Integridata, se deciden a implementar un DRP por acatar la recomendación de los auditores (60%) o porque el corporativo se los pide (30%), pero pocas lo hacen por convicción propia (10%). “De manera que la mayoría se conforma con implementarlo y no lo actualiza, dicen ya cumplí, no le dan el mantenimiento necesario y luego vienen los fracasos”.

Ese mantenimiento del que habla Cerezo involucra, entre otras cosas, probar constantemente el DRP, para ver si algo falló en el desarrollo metodológico.

Puede ser que el personal no conozca bien la infraestructura del negocio, a la mejor la plataforma de recuperación no es la adecuada o los procedimientos técnicos no están bien desarrollados, y todo eso se mide en las pruebas posteriores a la implementación.

¿Cuántas pruebas deben hacerse y cada cuándo? Lo que recomienda el estándar BS25999 (que plantea el uso de sistemas de administración de la continuidad del negocio) es probar el DRP cada seis meses y luego proceder a las actualizaciones pertinentes, para asegurar su vigencia.

En la primera prueba, realizada después de la implementación, se logra alcanzar apenas entre 45 y 50% de efectividad en el plan. “Eso es un rango normal, no hay por qué preocuparse. La experiencia dicta que es hasta la cuarta o quinta evaluación cuando el DRP está ya listo, cuando la empresa puede salir airosa de una contingencia ”, asegura Cerezo.

Desafortunadamente, ni siquiera las empresas que implementan su DRP plenamente convencidos de su importancia le dan a éste el seguimiento adecuado. De hecho, muchas no pasan de la segunda prueba, así que de 10% que desarrolla un DRP por convicción, sólo 7% puede salir adelante de un evento catastrófico.

“De las empresas que estaban en las torres gemelas sólo 20 o 25% se recuperaro de ese evento, porque tenían un plan, pero no le dieron seguimiento, ni mantenimiento y nunca probaron con la frecuencia requerida, si no cada dos años y eso no es funcional”, enfatiza Cerezo.

Y agrega: “no se vale hacer la prueba dos años después, porque la gente ambia, la infraestructura cambia, los cambios en tecnología son muy rápidos y también en la operación del negocio, y si no le das mantenimiento al plan, ya no te puedes recuperar”, subraya el consultor.

3.- Contar con todo lo necesario para cubrirse bien las espaldas. El siguiente reto es la disponibilidad tecnológica y de elementos críticos: tener, por ejemplo, los suficientes respaldos para recuperar toda la información sensible.

“En el mundo de los respaldos hay una parte olvidada: no todos los usuarios tienen un plan para respaldar su información, por eso conviene elaborar una política en la cual se asiente que todo el personal debe almacenar en un servidor y no sólo en su computadora. Claro que para esto se requiere definir qué se respalda y cada cuándo”, puntualiza Méndez.

Además, cuando hablas de un proceso de recuperación,

...