Un plan de continuidad de negocio responde a una pregunta muy concreta: si mañana no puedes usar tu oficina, tus sistemas o a un proveedor clave, ¿qué haces en la primera hora, el primer día y la primera semana para seguir atendiendo a tus clientes? Ayudamos a empresas de Madrid a construir esa respuesta con datos: qué procesos son críticos, cuánto tiempo pueden estar parados, qué hace falta para recuperarlos y quién decide qué.


Somos una empresa de servicios IT con 26 años de trayectoria, así que la parte tecnológica del plan (copias, sistemas, comunicaciones, accesos) no se queda en una recomendación genérica: la diseñamos, la implantamos y la probamos.

Qué es un plan de continuidad de negocio y qué no es

Se confunden a menudo tres cosas distintas que se complementan:


DocumentoPregunta que respondeAlcance
Plan de continuidad de negocio (BCP)¿Cómo seguimos operando durante una interrupción?Procesos, personas, sedes, proveedores, comunicación y tecnología
Plan de recuperación ante desastres (DRP)¿Cómo recuperamos los sistemas IT y en qué orden?Servidores, aplicaciones, datos, red y comunicaciones
Política de copias de seguridad¿Qué copiamos, con qué frecuencia y dónde?Datos y configuraciones

Las copias son una pieza del DRP, y el DRP es una pieza del plan de continuidad. Esta página trata del plan completo: lo que la dirección necesita para decidir y lo que el equipo necesita para actuar. El plan de recuperación ante desastres no se hace aparte, sino dentro del mismo proyecto, a partir de los objetivos que fija el análisis de impacto (si necesitas repasar el concepto, está en nuestro glosario de disaster recovery).

Qué incluye el plan de recuperación ante desastres

Para cada sistema crítico, el DRP documenta dónde están sus copias y réplicas, en qué orden se recupera (primero identidad, red y comunicaciones; después las aplicaciones de negocio), quién lo hace, cuánto tarda según la última prueba y cómo se comprueba que los datos recuperados son correctos. Incluye también los contactos de proveedores y fabricantes, las credenciales de emergencia custodiadas fuera de los sistemas afectados y los criterios para volver a la normalidad.

Cómo elaboramos el plan

Trabajamos en cinco fases. En una pyme con pocos procesos críticos, el primer plan utilizable suele cerrarse en semanas, no en meses; en organizaciones con varias sedes o mucha dependencia de proveedores el trabajo se escalona por áreas.

1. Análisis de impacto en el negocio (BIA)

Entrevistamos a los responsables de cada área para inventariar los procesos y medir qué pasa si se paran: pérdida económica, incumplimientos contractuales o legales, daño a clientes y a la reputación. De ahí sale, para cada proceso, el tiempo máximo de interrupción tolerable y las dependencias que tiene: personas, aplicaciones, datos, proveedores y ubicaciones.

Mapa de procesos sobre una mesa de reunión con tres procesos críticos destacados en el análisis de impacto
El análisis de impacto identifica qué procesos son críticos y de qué personas, sistemas y proveedores dependen.

2. Evaluación de riesgos

Identificamos qué puede interrumpir esos procesos y con qué probabilidad: un ransomware, la caída de un proveedor cloud, un corte eléctrico o de comunicaciones, la indisponibilidad de la oficina, la baja de una persona que concentra el conocimiento. Priorizamos por impacto y probabilidad, no por lo que sale en las noticias.

3. Estrategias de continuidad

Para cada proceso crítico definimos cómo se mantendrá o recuperará: teletrabajo seguro, centro alternativo, proveedor de respaldo, procedimientos manuales temporales, réplica de sistemas o recuperación desde copia. Cada estrategia lleva su coste, para que la dirección elija con números.

4. Plan de respuesta y comunicación de crisis

Redactamos el plan operativo: quién declara la crisis, quién forma el comité, árbol de llamadas, mensajes preparados para empleados, clientes y proveedores, y procedimientos paso a paso para cada escenario. Los procedimientos técnicos de recuperación se escriben como runbooks que un técnico puede seguir bajo presión.

5. Pruebas y mantenimiento

Probamos el plan con ejercicios de mesa y, cuando procede, con restauraciones y conmutaciones reales. Cada prueba deja un informe con lo que funcionó, lo que no y las acciones pendientes. Revisamos el plan al menos una vez al año y siempre que cambian sistemas, proveedores o la organización.

RTO, RPO y tiempo máximo de parada: cómo fijarlos

Tres valores convierten el plan en algo medible:


  • Tiempo máximo de interrupción tolerable (MTPD): a partir de cuándo la parada de un proceso causa un daño inaceptable.
  • RTO (objetivo de tiempo de recuperación): en cuánto tiempo debe volver a funcionar, siempre por debajo del MTPD.
  • RPO (objetivo de punto de recuperación): cuántos datos puedes permitirte perder, medido en tiempo desde la última copia válida.

Un ejemplo orientativo de cómo queda la tabla en una empresa de servicios (los valores reales salen de tu BIA):


ProcesoMTPDRTORPO
Atención a clientes y correo1 día4 horas1 hora
Facturación y ERP3 días1 día4 horas
Nóminas1 semana3 días1 día
Web corporativa2 días1 día1 día

Fijar estos objetivos tiene consecuencias directas en la tecnología: un RPO de una hora no se cumple con una copia nocturna. Lo explicamos en detalle en RPO y RTO para empresas.

Línea de tiempo de un incidente con la última copia válida antes y la recuperación del servicio después
El RPO mide los datos que se pueden perder antes del incidente; el RTO, el tiempo hasta recuperar el servicio.

La parte tecnológica: lo que suele fallar

Al revisar planes existentes encontramos casi siempre los mismos puntos débiles en la parte IT:


  • Copias que nunca se han restaurado. La copia existe, pero nadie sabe cuánto tarda en recuperarse ni si está completa. Sin una restauración probada, el RTO es un deseo.
  • Copias alcanzables por el atacante. Si la copia está en la misma red y con las mismas credenciales, un ransomware la cifra con todo lo demás. Hace falta una copia aislada o inmutable.
  • Dependencia de servicios cloud sin plan B. Microsoft 365, el ERP en la nube o la centralita virtual también fallan; hay que saber qué se hace mientras tanto y si los datos están copiados fuera del proveedor.
  • Accesos que dependen de una sola persona. Contraseñas de administración, MFA en el móvil de un empleado, contratos con el registrador del dominio a nombre de alguien que ya no está.
  • Comunicaciones. Sin línea de respaldo ni desvío de la centralita, la empresa queda incomunicada aunque los sistemas funcionen.

Estas carencias las resolvemos dentro del propio proyecto o con nuestros servicios gestionados y de ciberseguridad, de forma que el plan y la infraestructura dicen lo mismo.

Normativa y clientes que lo piden

Cada vez más empresas necesitan un plan de continuidad porque se lo exige un cliente, una licitación o la normativa de su sector, no sólo por prudencia:


  • NIS2: la directiva incluye la continuidad de las actividades, las copias de seguridad y la gestión de crisis entre las medidas de gestión de riesgos. En España la ley de transposición aún no se ha publicado; lo resumimos en nuestra guía de NIS2 para pymes.
  • Esquema Nacional de Seguridad (ENS): los proveedores de la administración pública deben acreditar medidas de continuidad proporcionales a la categoría del sistema.
  • Clientes del sector financiero: el reglamento DORA obliga a las entidades financieras a gestionar el riesgo de sus proveedores TIC, y esas exigencias llegan a los proveedores por contrato.
  • ISO 22301: es la norma internacional de gestión de la continuidad de negocio. Usamos su estructura como marco; si quieres certificarte, el plan te deja preparado para ello.

Esta información es general y no sustituye el asesoramiento jurídico: si una norma te obliga, conviene confirmarlo con tu asesor legal o de cumplimiento.

Sala de reuniones preparada para un simulacro de continuidad con portátiles, manos libres y carpetas del plan
Un ejercicio de mesa pone a prueba roles, decisiones y comunicaciones antes de que haga falta de verdad.

Qué entregamos

  • Inventario de procesos y análisis de impacto documentado, con MTPD, RTO y RPO por proceso.
  • Mapa de dependencias: personas, aplicaciones, datos, proveedores y ubicaciones.
  • Evaluación de riesgos priorizada.
  • Estrategias de continuidad con su coste estimado, para decisión de la dirección.
  • Plan de continuidad con roles, contactos, criterios de activación y comunicación de crisis.
  • Runbooks técnicos de recuperación para los sistemas críticos.
  • Calendario de pruebas e informe del primer ejercicio.

Cómo trabajamos en Madrid y fuera de Madrid

Las entrevistas y talleres los hacemos presencialmente en Madrid, en tus oficinas, o en remoto si tu equipo está repartido. Para sedes en el resto de España o en Portugal combinamos sesiones remotas con técnicos locales o partners coordinados por nosotros cuando hay que revisar infraestructura sobre el terreno.


Si ya tienes un plan, empezamos por revisarlo: comprobamos si sigue reflejando tus procesos y tu tecnología actual y si se ha probado alguna vez. Muchas veces el trabajo no es escribir uno nuevo, sino hacer que el que existe funcione. La continuidad también encaja con una consultoría IT más amplia cuando se revisa la estrategia tecnológica de la empresa.


Solicitar asesoría: cuéntanos qué procesos no pueden pararse y revisamos tu plan actual, tus copias y tus proveedores críticos.