Selección de ubicación de emergencia: matriz de evaluación para sitios de recuperación con verificación de cumplimiento

La elección del sitio de emergencia es una de las decisiones que, en caso de incidente, o funcionan de forma discreta y sin espectáculo, o fracasan de manera muy pública. Sobre el papel, «Recovery-Site» suena a un segundo centro de datos o a una ubicación en la nube. En la práctica se trata, sin embargo, de algo más: de la cuestión de si sus procesos críticos de negocio pueden volver a ponerse en marcha, en escenarios reales de interrupción (incendio, corte de energía, ransomware, fallo de un operador de red, problema en la cadena de suministro, evento natural, ausencia de personal), dentro del tiempo exigido y sin generar nuevos riesgos de cumplimiento y de seguridad.

Este artículo ofrece una matriz evaluable para sitios de recuperación —con criterios, ponderaciones, requisitos mínimos (criterios „knock-out“) y una comprobación de cumplimiento (Compliance-Check) adecuada como evidencia en auditorías. El público objetivo son la dirección de TI, Seguridad, Compliance, la gestión de riesgos y la dirección general con responsabilidad en TI: es decir, los roles que asumen la responsabilidad de las decisiones y que después deberán explicar por qué se eligió (o descartó) una ubicación.

Conceptos y objetivos: ¿qué debe exactamente proporcionar el sitio de recuperación?

Antes de comparar ubicaciones, debe definir el objetivo —de lo contrario estará comparando peras con manzanas.

• RTO (Recovery Time Objective): tiempo máximo tolerable de recuperación. Ejemplo: «El ERP debe volver a estar disponible en un plazo de 8 horas». El RTO es una directriz para la arquitectura, la automatización, la reserva de capacidad y los procesos operativos.
• RPO (Recovery Point Objective): pérdida máxima tolerable de datos medida en tiempo. Ejemplo: «pérdida máxima de datos de 15 minutos». El RPO determina los procedimientos de replicación, los intervalos de backup y la consistencia de los datos.
• Clases de carga de trabajo: no todos los sistemas requieren el mismo sitio de recuperación. Típicamente se emplean clases como «Tier 1 (crítico para el negocio)», «Tier 2 (importante)», «Tier 3 (secundario)» —cada una con RTO/RPO, dependencias y clasificación de datos.
• Tipo de sitio de recuperación:
  • Hot Site: operación casi inmediata posible, costes elevados, RTO/RPO bajos.
  • Warm Site: componentes básicos disponibles, activación con tiempo de preparación, costes medios.
  • Cold Site: infraestructura/espacio disponible, los sistemas deben ser desplegados, económico pero con alto RTO.

Importante: RTO/RPO no son valores deseables de TI, sino que deben derivarse de un Análisis de Impacto en el Negocio (Business Impact Analysis, BIA) (análisis de efectos sobre procesos, ingresos, obligaciones regulatorias y reputación). En las auditorías se espera cada vez más que RTO/RPO estén justificadas de forma trazable, aprobadas y revisadas periódicamente.

La elección de la ubicación es más que geografía: supuestos erróneos típicos

«Lejos es automáticamente mejor»

La distancia geográfica reduce riesgos comunes (p. ej., un corte regional de energía). A la vez suele incrementar la latencia, la dependencia de rutas de operadores y la complejidad operativa (p. ej., equipos de administración separados, cadenas de suministro distintas). Lo decisivo no son los «kilómetros», sino la separación de los dominios de riesgo: suministro energético, operadores de red, abastecimiento de agua, zonas de peligro, riesgos políticos, cadenas de suministro y disponibilidad de personal.

«La nube no es automáticamente conforme»

Las regiones cloud pueden ser operativamente muy robustas, pero no eximen de responsabilidad. Para el cumplimiento importan la residencia de datos, los controles de acceso, la registración de eventos, la gestión de claves (p. ej., HSM/KMS), la cadena de subcontratistas y la capacidad de salida. El sitio de recuperación no solo debe „funcionar“, sino estar controlado de forma demostrable.

„La copia de seguridad no basta como sitio de recuperación“

Las copias de seguridad son la última línea de defensa, pero no una arquitectura de recuperación. Sin procedimientos de RESTauración probados, capacidad de cómputo suficiente, rutas de red, gestión de DNS/certificados e IAM (Identity & Access Management), la copia de seguridad sigue siendo un repositorio de datos —no una continuidad operativa. En escenarios de ransomware se añade: las copias de seguridad deben protegerse contra manipulaciones (p. ej., inmutables, cuentas administrativas separadas, enfoques de air-gap).

Matriz de evaluación para sitios de recuperación: estructura, ponderación, criterios eliminatorios

Una matriz práctica combina:

• Criterios eliminatorios (obligatorios): Si no se cumplen, la ubicación se descarta independientemente de la puntuación.
• Criterios de puntuación (debe/puede): valoración 0–5 o 0–10, con ponderación según la relevancia.
• Evidencias: para cada criterio debe quedar claro qué pruebas se aceptan (contrato, informe de auditoría, diagrama arquitectónico, protocolo de pruebas, descripción de procesos).

Ejemplo: escala y ponderación

Ha funcionado bien una escala 0–5 (0 = no existe, 3 = cumplido, 5 = supera), más una ponderación por categoría (p. ej., 25 % operación/resiliencia, 25 % seguridad/cumplimiento, 20 % red/conectividad, 15 % datos/plataforma, 15 % costes/contrato). La ponderación debe depender del apetito de riesgo y de las clases de proceso. Para workloads de Tier‑1, „costes“ raramente debe ponderarse por encima de „asegurar la capacidad de recuperación“.

Criterios eliminatorios (obligatorios) — realistas para muchas organizaciones

• Residencia de datos y jurisdicción: las categorías de datos pueden procesarse en la ubicación (protección de datos, normativa sectorial, contratos con clientes).
• RTO/RPO alcanzables en principio: plausibles sobre la base de la arquitectura y la capacidad, no solo alegados.
• Dominios de administración separados: posibilidad de operar el entorno de recuperación con identidades/clave separadas (importante frente a ransomware y riesgos internos).
• Controles de seguridad físicos y lógicos demostrables: acceso físico, segmentación, registro, gestión de parches/vulnerabilidades, procesos de incidentes.
• Servicios contractuales de emergencia: derechos de activación, prioridades en caso de crisis, ventanas de prueba, SLAs/OLAs claros, reglas de salida.

Categoría 1: perfil de riesgo y ubicación (geografía, infraestructura, efectos en cascada)

Para la elección de ubicaciones de emergencia debe considerar el perfil de la ubicación como un „paquete de riesgo“.

Preguntas de verificación

• Riesgo compartido: ¿comparten el sitio primario y el de recuperación las mismas dependencias de energía o de operador (el mismo conjunto de subestaciones, la misma canalización de fibra, los mismos puntos de acceso)?
• Zonas de riesgo: ¿se encuentra la ubicación en zonas de inundación, sísmicas, industriales o de alto riesgo? No solo históricamente, sino según mapas actuales y desarrollos locales.

Perspectiva de auditoría: Lo decisivo no es que elimine cada peligro natural, sino que haya conscientemente elegido y documentado: supuestos de riesgo, medidas mitigadoras y riesgo residual.

Categoría 2: Capacidad técnica de recuperación (RTO/RPO, capacidad, automatización)

Aquí se decide si el sitio de recuperación „solo existe“ o si es operativamente viable.

Modelo de capacidad en lugar de intuición

Una evaluación robusta del emplazamiento necesita un modelo de capacidad: qué cargas de trabajo deben ejecutarse en caso de emergencia, con qué requisitos de rendimiento (CPU/RAM/IOPS), durante cuánto tiempo y con qué dependencias (servicios de directorio, PKI, DNS, hora/NTP, broker de mensajería, interfaces). Punto débil frecuente: se considera solo la aplicación, no el ecosistema (identidad, monitorización, registro, gestión de secretos, trabajos por lotes, socios de integración).

Evaluar los mecanismos de recuperación

• Replicación (sincrónica/asíncrona): La replicación sincrónica reduce el RPO, pero exige baja latencia y enlaces estables; la asíncrona es más robusta, aunque puede generar brechas de datos.
• Copia de seguridad/RESTauración: Los tiempos de RESTauración deben medirse (no estimarse). Esto incluye recuperación de bases de datos, reconstrucción de índices, RESTauración de object storage y configuración de la aplicación.
• Infraestructura como Código (IaC): La provisión automatizada reduce errores bajo estrés. La gobernanza es importante: IaC debe estar versionado, aprobado y probado.
• Runbooks: Secuencias de pasos para failover y failback, con responsabilidades, aprobaciones y vías de comunicación.

Bloque de evidencia reutilizable: Prueba mínima de DR

Para auditorías ayuda un protocolo de prueba estandarizado. Ejemplo como plantilla:

Protocolo de prueba DR (forma abreviada)

1) Alcance
- Cargas de trabajo / clase de proceso:
- Valores objetivo: RTO ____, RPO ____
- Tipo de prueba: Tabletop / prueba parcial / prueba completa / no anunciada

2) Requisitos previos
- Aprobaciones (TI, área de negocio, Compliance):
- Ventana de cambios:
- Canales de comunicación / contactos:

3) Ejecución (marcas temporales)
- Hora de inicio de la simulación del incidente:
- Disparador de failover:
- Identidad/Acceso activo:
- Estado de datos verificado (punto de medición de RPO):
- Verificación de la aplicación (pruebas smoke):
- Socios de integración validados:
- Monitorización/registro activos:
- Aceptación por el negocio:

4) Resultado
- RTO alcanzado:
- RPO alcanzado:
- Desviaciones / causas:
- Medidas inmediatas:
- Plan de acciones con responsable y fecha:

5) Anexos de evidencia
- Estado de la arquitectura (versión del diagrama):
- IDs de tickets / registros de cambio:
- Valores medidos / capturas de pantalla del monitoreo:
- Aprobaciones / aceptaciones:

Categoría 3: Red, conectividad y «failover de la realidad»

Muchos conceptos de recuperación no fracasan por la capacidad de cómputo, sino por detalles de red: DNS, enrutamiento, certificados, espacios de direcciones IP, reglas de firewall, conectividad con socios, variantes de MPLS/VPN/Direct-Connect.

Criterios de evaluación

• Canales de enlace independientes: La redundancia solo es eficaz si no circula por el mismo corredor físico (palabra clave «Diverse Routing»).
• Mecánica de failover: DNS-TTL, Anycast, BGP-Failover o conmutación de balanceadores de carga — cada uno con responsabilidad operativa clara.
• Conexiones con socios y terceros: ¿Pueden interfaces críticas (p. ej. proveedores de pago, logística, EDI) conmutar a la Recovery-Site? ¿Existen posibilidades contractuales de prueba?
• Segmentación: Separación de redes de administración, datos y aplicaciones, incluido el funcionamiento de emergencia (p. ej. acceso RESTringido, jump hosts, MFA).

Nota de gobernanza: Documente qué cambios de red son admisibles en emergencia sin CAB (Change Advisory Board), qué autorizaciones „Break-Glass“ se aplican y cómo se realiza la documentación posterior.

Categoría 4: Datos, requisitos de protección y residencia de datos

La selección de la Recovery-Site también es arquitectura de datos. Los conflictos típicos surgen entre la recuperación rápida y la clasificación estricta de datos.

Puntos de comprobación para datos y plataforma

• Clasificación de datos: ¿Qué datos pueden ir a qué ubicación? (personales, confidenciales, sujetos a control de exportación, secretos empresariales). La Recovery-Site debe permitir el procesamiento de estas clases — incluido el acceso de administración y soporte.
• Cifrado: en reposo y en tránsito. Es crucial quién controla las claves (claves del cliente vs. claves del proveedor) y cómo se regulan la rotación de claves y el acceso de emergencia.
• Modelos de consistencia: Bases de datos, colas de mensajes, sistemas de archivos. El RPO es inútil si las aplicaciones quedan en estados inconsistentes tras la recuperación (p. ej. duplicaciones de asiento, pedidos huérfanos).
• Retención & WORM/Immutability: Para ciertos datos la inmutabilidad (Write Once Read Many) puede ser relevante. Compruebe si la Recovery-Site soporta este modo de operación.

Categoría 5: Security-Controls contra ransomware y riesgos transversales

Una Recovery-Site que opere en el mismo contexto de seguridad que el entorno primario será arrastrada rápidamente en caso de compromiso de identidades o administradores. Una buena elección de ubicación significa también: hacer que el aislamiento sea planificable.

Criterios concretos

• IAM separado / cuentas de administrador separadas: Al menos roles separados y MFA fuerte; idealmente un dominio de directorio separado o una zona de identidad claramente segmentada.
• Proceso Break-Glass: acceso de emergencia con autorización documentada, registro exhaustivo y control posterior.
• Registro y análisis forense: los registros de seguridad deben estar disponibles centralmente incluso en modo de emergencia (conexión a SIEM, registros inmutables, sincronización horaria vía NTP).
• Gestión de vulnerabilidades y parches: el sitio de recuperación no debe «quedarse años sin actualizar» y, en caso de emergencia, arrancar sin parches. Actualización al menos mensual, además de evidencia de la línea base.

Bloque de política copiable: Break-Glass (política breve)

Acceso Break-Glass (versión abreviada de la política)

Propósito:
- Permite operaciones de recuperación en caso de fallo/compromiso de accesos administrativos regulares.

Reglas:
- Cuentas de emergencia separadas, no para operación diaria.
- MFA obligatorio, preferencia por tokens hardware.
- Activación sólo tras autorización de 2 personas (dirección de TI + Security/Compliance).
- Cada uso genera un ticket de incidente y se documenta adicionalmente en un plazo de 24 h.
- Las sesiones se registran (Command Logging / Session Recording, si está disponible).
- Las cuentas de emergencia se prueban trimestralmente y las contraseñas/secretos se rotan.

Evidencia:
- Lista de cuentas, roles, últimas pruebas, registros de activación, protocolo de revisión.

Categoría 6: Control de cumplimiento (auditable): qué evidencias debe solicitar desde el inicio

La parte de cumplimiento suele considerarse con retraso – entonces los contratos están firmados, las decisiones técnicas tomadas y faltan las evidencias. Para una selección de sitio de recuperación auditable es crucial que incorpore los requisitos en adquisición, acuerdos contractuales y operación.

Puntos de referencia regulatorios (sin carácter exhaustivo)

• ISO 22301 (Business Continuity Management): exige, entre otros, BIA, análisis de riesgos, estrategias de reinicio, ejercicios, procedimientos documentados y mejora continua.
• DORA (Digital Operational Resilience Act): relevante para muchos participantes del mercado financiero; enfatiza resiliencia, capacidad de prueba, riesgos de terceros y gobernanza.
• BAIT/VAIT/KAIT (requisitos regulatorios en Alemania, según el sector): enfoque típico en conceptos de emergencia, externalizaciones, seguridad de la información y documentación de evidencias.
• KRITIS/NIS2-Kontext: según la afectación, requisitos adicionales sobre medidas de seguridad, obligaciones de notificación y resiliencia.
• DSGVO: tratamiento, encargamiento del tratamiento, TOMs (medidas técnicas y organizativas), transferencias a terceros países, conceptos de eliminación.

Importante: no debe «cumplir» con cada norma, pero debe saber cuáles afectan a su organización – y cómo su sitio de recuperación respalda esos requisitos.

Lista de verificación de cumplimiento para sitios de recuperación (orientada a evidencias)

• Contrato y externalización
  • Descripción del servicio para operación de emergencia (activación, priorización, compromisos de capacidad).
  • Derechos para pruebas/ejercicios (frecuencia, alcance, reglas de costes).
  • Transparencia y consentimiento de subcontratistas, incluida la cadena de ubicaciones.
  • Estrategia de salida: devolución de datos, eliminación, migración, plazos, asistencia.
• Protección de datos
  • Roles (responsable/encargado del tratamiento), AVV, anexo de TOMs.
  • Residencia de datos y reglas de transferencia a terceros países, accesos desde terceros estados.
  • Concepto de eliminación y retención también en modo de emergencia (p. ej. datos de prueba, registros).
• Seguridad y operación
  • Evidencia de control de accesos, monitorización, gestión de incidentes, gestión de cambios.
  • Registro y retención (registros de auditoría, actividades de administración).
  • Pruebas DR periódicas con resultados documentados y planes de medidas.

Categoría 7: Operación diaria: ¿Quién hace qué cuando realmente hay una emergencia?

Los sitios de recuperación se adquieren técnicamente y luego se olvidan organizativamente. En una auditoría o en un incidente eso sale a la luz. Lo decisivo es la operatividad bajo estrés: roles, facultades, comunicación y lógica de decisión.

Roles y responsabilidades (lógica RACI)

• Dirección de TI: Decisión «failover sí/no», priorización de recursos, escalado a la dirección ejecutiva.
• Service Owner / responsables de aplicaciones: Validación de smoke tests, dependencias, aceptación técnica.
• Seguridad: Autorización de accesos de emergencia, monitorización, indicadores de compromiso (para no arrancar un entorno «infectado»).
• Cumplimiento/Gestión de riesgos: Obligaciones de documentación y de prueba, comunicación a la autoridad supervisora/partes interesadas según el contexto.
• Gestión de proveedores/contratistas: Activación de pRESTaciones contractuales, coordinación de subcontratistas.

Regla práctica: si su sitio de recuperación sólo puede realizar un failover con «los dos administradores senior», eso es un riesgo. Planifique capacidad de turnos, suplencias y transferencia de conocimiento. Eso es un criterio en la evaluación de la ubicación, porque determina las consecuencias operativas.

Categoría 8: Realidad de costes y contratos: Lo que debe reflejar en el modelo TCO

Los costes con frecuencia se reducen a la infraestructura („segunda ubicación = hardware duplicado“). En la realidad se generan bloques de coste en operación, pruebas, licencias, conectividad y gobernanza.

Componentes TCO típicos

• Reserva de capacidad: capacidad de cómputo reservada, almacenamiento, clústeres de bases de datos, en su caso costes de licencias en standby.
• Conectividad: líneas redundantes, cross-connects, firewalls adicionales, protección contra DDoS.
• Operativa de pruebas: ejercicios DR, ventanas de mantenimiento, esfuerzos del área de negocio, documentación.
• Controles de seguridad: integración SIEM, EDR, PAM (gestión de accesos privilegiados), registro de sesiones.
• Salida & Portabilidad: exportación de datos, herramientas de migración, duplicidad de competencias/formación.

Consejo de la matriz de evaluación: los costes no deberían contabilizarse solo como una cifra absoluta, sino también como riesgo de coste (p. ej. lógica de precios poco clara en caso de emergencia, cláusulas „Best Effort“, tarifas por prueba, falta de garantía de capacidad).

Cómo aplicar la matriz de evaluación en la práctica (modelo de procedimiento en 6 pasos)

1. Definir el alcance: clases de proceso, workloads, clases de datos, dependencias, RTO/RPO.
2. Establecer criterios obligatorios: lista knock-out, incluyendo cumplimiento.
3. Catalogar criterios: Categorías (riesgo/ubicación, tecnología, red, datos, seguridad, operación, contrato, costes).
4. Decidir la ponderación: por IT, Seguridad, Cumplimiento y representación del área de negocio (por clase de Tier).
5. Exigir evidencias: pruebas aceptadas por criterio; la falta de evidencia cuenta como «no cumplido».
6. Revisión & decisión: resultado, riesgo residual, plan de medidas, fecha para re-evaluación (p. ej. anual o ante cambios de ubicación/proveedor).

Bloque de matriz copiable: lista de criterios (versión corta para empezar)

Matriz de evaluación sitio de recuperación – Inicio rápido (0–5 puntos, ponderación por categoría)

A) Perfil de ubicación/riesgo
- Independencia energía/carrier
- Zonas de peligro / riesgos compartidos
- Accesibilidad / disponibilidad de personal

B) Capacidad RTO/RPO
- Replicación/procedimientos de backup comprobables
- Capacidad y escalado en caso de emergencia
- Automatización (IaC/runbooks)
- Pruebas periódicas (frecuencia, alcance, resultados)

C) Red & Connectivity
- Diversidad de rutas de enlace
- Mecánica de conmutación por error (DNS/BGP/balanceador de carga)
- Conexiones con socios conmutables
- Segmentación & accesos de administrador

D) Datos & Protección de datos
- Residencia de datos / jurisdicción
- Cifrado & propiedad de claves
- Retención/eliminación también en modo de emergencia

E) Seguridad
- Dominios administrativos separados / Break-Glass
- Registro/forense/SIEM
- Gestión de parches/vulnerabilidades

F) Gobernanza/Contrato/Costes
- Derechos de activación, SLAs/OLAs, derechos de prueba
- Subcontratistas/cadena de suministro transparentes
- Estrategia de salida y devolución de datos
- Modelo de costes (incl. pruebas, operación de emergencia)

Perspectiva de auditoría: lo que los auditores suelen querer ver

Independientemente de si la auditoría es interna o externa: se obtienen buenos resultados cuando documenta las decisiones como una cadena verificable. Puntos de verificación típicos:

• Fundamento: BIA y análisis de riesgos conducen a RTO/RPO y a la estrategia de ubicación.
• Implementación: La arquitectura y los conceptos operativos muestran cómo se alcanzan los objetivos.
• Eficacia: Las pruebas/ejercicios demuestran que no es solo teoría.
• Mejora: Las desviaciones generan medidas con un responsable y una fecha.
• Terceros: La gestión de la externalización y la salida están reguladas, no solo „en alguna parte del contrato“.

Si desea profundizar internamente: un catálogo estructurado de preguntas de auditoría ayuda a recopilar la evidencia desde el principio y a cerrar brechas antes de la siguiente auditoría o ejercicio.

Conclusión final: La buena elección de un sitio de emergencia es una decisión con carga de prueba

Un sitio de recuperación no es un símbolo de resiliencia, sino un modo de operación sólido. La mejor elección de sitio de emergencia se logra cuando tecnología, operaciones y cumplimiento se evalúan conjuntamente: con criterios imprescindibles, un sistema de puntuación verificable, evidencias claras y pruebas periódicas. De ese modo, la decisión no solo es sostenible en modo de crisis, sino también explicable en rondas presupuestarias y auditorías — incluidos los riesgos residuales asumidos.

El paso decisivo suele no ser la elección „del sitio perfecto“, sino la lógica de implementación consistente: capturar completamente las dependencias, planificar la aislamiento frente a ataques transversales, asegurar contractualmente los derechos de prueba y traducir los resultados a la gobernanza. Entonces el sitio de recuperación no solo existe, sino que está listo para operarlo.

Para este tema también son importantes el sitio de recuperación y la recuperación ante desastres. El artículo sitúa estos aspectos de forma comprensible y muestra en qué hay que fijarse en el día a día.