El problema no es que tu empresa pueda sufrir una caída.
El problema es no saber cuánto tiempo puedes estar parado… ni cuánto dato puedes permitirte perder.
Ahí es donde entran dos conceptos que casi nadie en pymes y asesorías entiende bien:
RTO y RPO.
No son términos técnicos.
Son decisiones de negocio.
Y si no las has tomado de forma consciente, alguien ya las ha tomado por ti… sin que lo sepas.
Si te inquieta descubrir que tener sistemas no es suficiente, profundiza en nuestro análisis «Cuando internet se cae, no pierdes conexión: pierdes tu capacidad de facturar».
Qué es el RTO (Recovery Time Objective) y por qué define si tu negocio sobrevive
El RTO (Tiempo Objetivo de Recuperación) es el tiempo máximo que tu empresa puede estar parada tras un incidente.
No es lo que te gustaría.
Es, en realidad, lo que tu negocio puede soportar sin impacto crítico.
Ejemplo real:
- Si tu despacho está 8 horas sin sistema → ¿puedes seguir operando?
- Si son 24 horas → ¿pierdes clientes?
- Si son 3 días → ¿tu facturación se rompe?
El RTO no es técnico.
Es, en realidad, una decisión estratégica.
Define cuánto tiempo puedes permitirte no trabajar.
Qué es el RPO (Recovery Point Objective) y el dato que estás dispuesto a perder
El RPO (Punto Objetivo de Recuperación) indica cuánto dato puedes perder.
Ejemplo:
- Backup diario → puedes perder hasta 24h de trabajo
- Backup cada hora → pierdes máximo 60 minutos
La pregunta clave no es técnica:
¿Cuántas horas de trabajo estás dispuesto a rehacer?
Porque, si no puedes rehacerlas, simplemente no puedes permitirte perderlas.
El error más común: tener copias… sin tener RTO ni RPO definidos
La mayoría de las empresas dicen: “Tenemos backups, estamos tranquilos.”
Pero no saben responder:
- ¿Cuánto tardamos en recuperar todo?
- ¿Qué sistemas van primero?
- ¿Qué datos se perderían?
- ¿Quién ejecuta la recuperación?
- ¿Está probado?
Esto no es continuidad operativa, sino una falsa sensación de seguridad.
RTO y RPO no son IT: son cumplimiento normativo (y responsabilidad real)
Si te inquieta descubrir que tener sistemas no es suficiente, profundiza en nuestro análisis Cuando internet se cae, no pierdes conexión: pierdes tu capacidad de facturar.
El Reglamento General de Protección de Datos, en su Artículo 32, establece:
“Capacidad de garantizar la disponibilidad y el acceso a los datos personales de forma rápida en caso de incidente físico o técnico.”
Esto conecta directamente con:
- RTO → rapidez de recuperación
- RPO → integridad de la información
Y añade un punto crítico:
“Proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas.”
No basta con tener backups.
Debes poder demostrar:
- Que funcionan
- Que están alineados con tu operativa
- Que has definido tiempos y pérdidas asumibles
Si quieres saber qué evidencias te pedirían en una inspección real, consulta Art. 32 RGPD: si te pidieran las evidencias en 72 horas, ¿qué podrías entregar exactamente?.
Lo que nadie te dice: tu RTO y RPO ya existen (aunque no los hayas definido)
Si nunca has trabajado estos conceptos, tu empresa ya tiene:
- Un RTO real → el tiempo que tardas en recuperarte “como puedas”
- Un RPO real → el último backup disponible (si funciona)
El problema es claro:
no están diseñados, no están validados y no están alineados con tu negocio.
Y eso es lo que provoca:
- Paradas de días
- Pérdidas de información irreversibles
- Decisiones improvisadas bajo presión
Cómo empezar a definir RTO y RPO sin ser técnico
No necesitas ser informático.
Necesitas hacerte estas preguntas:
- ¿Qué sistemas son críticos?
- Contabilidad
- CRM
- Correo
- Plataforma fiscal
Para ver ejemplos concretos de cómo los negocios se paralizan aunque “todo funcione”, te recomendamos leer No necesitas una caída para parar tu empresa: estás operando en condiciones perfectas (y ese es el problema).
- ¿Cuánto tiempo puedo estar sin cada uno?
→ Eso define tu RTO - ¿Cuánto dato puedo perder en cada uno?
→ Eso define tu RPO - ¿Tengo capacidad real de cumplirlo?
→ Aquí empieza el problema (o la estrategia)
La mayoría de empresas no sabe responder a esto hasta que falla algo.
Y ahí es cuando, normalmente, ya es tarde.
Por eso trabajamos revisando RTO, RPO y capacidad real de recuperación antes de que ocurra un incidente.
No se trata de tener más tecnología.
Se trata de saber si lo que tienes realmente te permite seguir trabajando cuando algo falla.
Ahí es donde empieza una estrategia de continuidad real.
Si mañana tu sistema deja de funcionar…
¿sabes exactamente cuánto tardarías en volver a operar… y qué habrías perdido?
¿puedes asumirlo sin impacto económico?
Este artículo forma parte de una visión más amplia: descubre por qué “cumplir” no basta en Cumplir RGPD es demostrarlo: la realidad que nadie cuenta a las asesorías.
El RTO mide el tiempo máximo de recuperación. El RPO mide la cantidad de datos que puedes perder.
No se mencionan como tal en el RGPD, pero son necesarios para cumplir el Art. 32 sobre disponibilidad y recuperación.
No. Solo si están diseñados, verificados y alineados con tiempos reales de recuperación.
No. Depende de su operativa, dependencia tecnológica y tolerancia a la pérdida.
