LazarMinds ha publicado un Plan de Contingencia para datos especialmente dirigido a dueños de negocios y empresas, administradores y asesores de sistemas.
Es un plan aplicable a casi cualquier situación de emergencia o desastre, solo hay que modificar lo necesario, espero le sea de utilidad.
Un fragmento del documento:
En vista de las situación actual se propone la elaboración de un plan de contingencia en caso de emergencia y/o desastre para el resguardo de la data empresarial.
En la actualidad tecnológica que estamos viviendo la data informática a pasado a formar parte de lo que se llamarían “Activos Intangibles”, las empresas se han hecho cada vez mas dependientes de sus registros mercantiles electrónicos.
Recordando los hechos ocurridos el 11 de Septiembre de 1999 en los Estados Unidos observamos que, transcurridos los eventos que enlutaron al pueblo norteamericano muchas empresas fueron a la quiebra debido a la perdida total de sus datos.
En la situación nacional actual no existe garantías de un ambiente calmado y pacífico, en caso de una tragedia y/o desastre, aparte del resguardo de la integridad física y de la vida de los empleados, se deben tomar medidas que resguarden nuestra data.
Proponemos el siguiente plan de contingencia, para ser ejecutado siempre y cuando no arriesgue la integridad física de los trabajadores, y tomando en cuenta que la situación de emergencia pueda ser prevista.
La descarga del plan en MassMirror ya no responde, así que no se ofrece como descarga; el fragmento del documento queda aquí como contenido del artículo.
Un plan de contingencia hoy: lo que no puede faltar
Nota sobre el fragmento: el documento cita «11 de Septiembre de 1999»; los atentados a los que se refiere ocurrieron el 11 de septiembre de 2001, y su lección es la que el propio fragmento señala: muchas empresas quebraron por la pérdida total de sus datos. Esa lección es la base de cualquier plan de contingencia actual, y sus piezas no cambiaron: primero la integridad física de las personas, siempre por encima de los datos; luego copias de seguridad probadas y fuera del sitio principal (una copia que nunca se probó restaurar no es una copia); un orden de recuperación por criticidad; responsables definidos; y un simulacro periódico, porque un plan que nunca se ejecutó es solo un documento.
Hoy se añade lo que en 2007 apenas se nombraba: ransomware y borrado malicioso, que obligan a copias inmutables y a credenciales separadas para restaurar, y la nube como segundo sitio. Pero el principio del plan de LazarMinds sigue intacto: se ejecuta solo si no arriesga la integridad física de los trabajadores, y se adapta a la emergencia concreta, no se aplica a ciegas.
