Un contrato de nube que garantiza una alta disponibilidad mide si el servicio responde, no si usted puede recuperar sus datos cuando están cifrados por un atacante, corrompidos por un error de configuración o borrados por una cuenta con permisos excesivos. Son dos garantías distintas, y confundirlas es el origen de buena parte de las sorpresas desagradables en una crisis. El ataque a Change Healthcare, en febrero de 2024, dejó semanas de interrupción en el procesamiento de reclamaciones y en farmacias de todo Estados Unidos, con un costo divulgado cercano a 2.460 millones de dólares hasta fin de ese año (arXiv, 2025). No es un caso de nube mal contratada; es un recordatorio de que la capacidad de volver a operar se construye y se prueba antes del incidente.
Este artículo no vuelve sobre la ciberseguridad del PACS ni sobre las cifras de brechas ya revisadas en otros textos del blog. Trata de la resiliencia: qué diferencia a la disponibilidad de la recuperación, cómo se definen los objetivos de tiempo y de pérdida de datos desde los servicios clínicos, cómo se reparte la responsabilidad con el proveedor y cómo se prueba una restauración sin interrumpir la atención.
Tres conceptos que no son lo mismo: disponibilidad, respaldo y recuperación
La alta disponibilidad protege frente a la falla de un componente: si un servidor se cae, otro toma su lugar. El respaldo conserva copias de los datos para poder volver a un estado anterior. La recuperación ante desastres es la capacidad de restablecer el servicio completo, incluidos los sistemas de los que depende. Un resumen técnico de buenas prácticas lo expresa con claridad: el respaldo atiende las copias de datos, y la recuperación atiende la capacidad de la organización para seguir atendiendo pacientes, agendando citas y facturando (Konfirmity, 2026).
Ninguno sustituye a los otros. Un servicio de alta disponibilidad replica instantáneamente un borrado accidental a todas sus réplicas. Un respaldo sin plan de restauración deja una pila de copias que nadie sabe en qué orden devolver. Y un plan de recuperación que nunca se ha ejecutado es una hipótesis.
RTO y RPO se definen por servicio clínico, no por el área de TI
El objetivo de tiempo de recuperación (RTO) es cuánto puede tardar un servicio en volver a funcionar; el objetivo de punto de recuperación (RPO) es cuánta información reciente se puede perder, medida en tiempo. La confusión más frecuente es que se fijan por sistema técnico, cuando deberían fijarse a partir de la necesidad clínica: ¿cuánto tiempo puede esperar un paciente de urgencias a que su estudio esté disponible?, ¿cuántos informes en curso puede permitirse perder un servicio antes de que el trabajo perdido sea inaceptable?
Una forma práctica es clasificar los servicios en niveles y asignar a cada uno objetivos distintos. La tabla siguiente es un ejemplo de método, con valores cualitativos; cada institución debe fijar los suyos con los jefes de servicio.
| Nivel | Ejemplos en un centro de imágenes | RTO orientativo | RPO orientativo |
|---|---|---|---|
| 1. Crítico para la atención en curso | Visualización de estudios de urgencias, lista de trabajo del RIS, identificación del paciente | Minutos a pocas horas | Minutos |
| 2. Necesario el mismo día | Informes en elaboración, agenda del día, entrega de resultados | Horas | Menos de una hora a pocas horas |
| 3. Necesario en los días siguientes | Facturación, portal de pacientes, mensajería | Un día o más | Hasta un día |
| 4. Archivo y análisis | Estudios históricos, tableros de gestión | Varios días | Un día o más |
Un punto técnico que suele pasarse por alto en imagenología: el RIS, el PACS y el portal deben recuperarse a un punto en el tiempo consistente entre sí. Si el RIS se restaura a las 10:00 y el PACS a las 08:00, quedan estudios sin orden, órdenes sin estudio y números de acceso desalineados, un problema que se habría evitado diseñando el RPO del conjunto y no de cada pieza.
Responsabilidad compartida: qué corresponde al proveedor y qué a la institución
En un modelo de nube, el proveedor responde por la infraestructura física, la virtualización y la disponibilidad del servicio que ofrece. La institución responde por lo que pone encima: los datos, las identidades y los accesos, las configuraciones, las políticas de retención y las pruebas de restauración. La línea exacta varía según el tipo de servicio, y ese es precisamente el motivo para escribirla en el contrato y no suponerla.
En Colombia hay además una capa legal. La Ley 1581 de 2012 distingue al responsable del tratamiento, que decide sobre la base de datos, del encargado, que trata los datos por cuenta del responsable (Congreso de la República, 2012). En la computación en la nube, la institución de salud es el responsable y el proveedor, el encargado. La Superintendencia de Industria y Comercio recomienda que el contrato de servicios en la nube limite la finalidad del tratamiento, imponga al proveedor el deber de confidencialidad y regule cómo se manejan los requerimientos de acceso a los datos, y advierte que cuando los servidores están fuera de Colombia debe observarse el artículo 26 de la ley sobre transferencia a terceros países (Superintendencia de Industria y Comercio, s. f.). Aceptar los términos estándar del proveedor sin revisar estos puntos deja a la institución con una obligación que no puede demostrar.
Clasificación de datos, cifrado y llaves
No todos los datos de una institución exigen el mismo nivel de protección ni el mismo costo de almacenamiento. Clasificar los datos —imágenes y reportes clínicos, datos de identificación, información administrativa, registros de auditoría— permite decidir dónde se almacena cada categoría, con qué cifrado, por cuánto tiempo y quién accede. La gestión de las llaves de cifrado merece una decisión explícita: si las controla el proveedor, la institución depende de él para acceder a su propia información; si las controla la institución, asume la responsabilidad de custodiarlas y de recuperarlas. Cualquiera de las dos opciones es defendible, pero debe estar escrita y probada.
La residencia de los datos y la portabilidad completan el análisis contractual. Conviene saber en qué países están los centros de datos, qué subcontratistas intervienen, en qué formatos y en cuánto tiempo se pueden exportar los estudios y los informes si la relación termina, y cuánto costaría. Un archivo de imágenes en formato estándar es portable en teoría; solo una exportación de prueba demuestra que lo es en la práctica.
Respaldo inmutable y separación del plano de control
Un respaldo inmutable es una copia que no puede modificarse ni borrarse durante su período de retención, ni siquiera por una cuenta administradora o por un programa malicioso. Es la defensa más directa contra el cifrado de copias por ransomware, y por eso aparece en la mayoría de las guías. Pero tiene una condición que suele olvidarse: la inmutabilidad no sirve si la copia comparte con producción la misma identidad, el mismo plano de administración o las mismas credenciales. Un análisis de 2026 sobre la nueva versión del perfil de ransomware del NIST advierte que la evidencia de recuperación pierde valor cuando las copias dependen de las mismas rutas de control que los sistemas de producción, y recomienda usar el mapeo del perfil para revelar dependencias que los inventarios de controles pasan por alto, como la identidad, la administración y el control de respaldos compartidos (Security.io, 2026).
La recomendación práctica es mantener al menos una copia en un entorno aislado, con identidad y credenciales propias, autenticación multifactor y sin conectividad permanente con producción, desde el cual pueda restaurarse la operación aunque el entorno principal esté comprometido.
El estándar de referencia: NIST IR 8374 revisión 1
En junio de 2026, el NIST publicó la versión final de la revisión 1 de la guía IR 8374, un perfil comunitario del Marco de Ciberseguridad 2.0 dedicado al riesgo de ransomware. El documento organiza los resultados de seguridad que ayudan a gobernar, identificar, proteger, detectar, responder y recuperarse de un ataque de ese tipo, y puede usarse para medir el grado de preparación de una organización y para elaborar un manual de respuesta (Souppaya et al., 2026; NIST NCCoE, 2026). Sustituye a la versión de 2022. Para una IPS, su utilidad práctica es doble: ofrece un lenguaje común para conversar con el proveedor de nube y una lista de resultados que se puede convertir en preguntas de auditoría, desde quién es el responsable del riesgo hasta cómo se verifica que una copia se puede restaurar.
Cómo probar la restauración sin interrumpir la atención
La prueba de restauración es la única que convierte un objetivo en un dato. Se puede hacer sin tocar producción: se restaura una copia en un entorno aislado y se mide el tiempo hasta que el servicio responde, comparándolo con el RTO del nivel correspondiente, y la antigüedad de los datos restaurados, comparándola con el RPO. Una prueba útil incluye cuatro verificaciones: que el estudio se abre y se visualiza correctamente, que el conteo de estudios y de informes coincide con el registro de origen, que los números de acceso son consistentes entre el RIS y el PACS y que los usuarios con los permisos correctos acceden y los demás no.
Un calendario razonable combina pruebas parciales frecuentes (restaurar un estudio o una base pequeña) con ejercicios completos periódicos que incluyan el orden de restauración entre sistemas, la participación de los jefes de servicio y un informe con lo aprendido. Cada resultado debe archivarse como evidencia de que el plan funciona y no solo existe.
Caída de conectividad: diseñar para el modo degradado
Una institución que depende de la nube para operar necesita saber qué hace cuando la conexión falla, que es una causa mucho más frecuente de interrupción que un desastre. Las arquitecturas híbridas, con almacenamiento y servicios esenciales en sitio y copia en la nube, ofrecen esa capacidad: el equipo puede seguir adquiriendo y leyendo estudios con la caché local mientras la conexión se restablece. El diseño debe incluir un procedimiento de contingencia para el personal, con formatos de respaldo en papel y reglas para incorporar después lo registrado durante la caída, como se describe en el artículo sobre gestión documental. En este enfoque, la recuperación deja de ser un proyecto del área de TI y se convierte en una capacidad del negocio, con responsables, indicadores y presupuesto.
Cinco preguntas para el proveedor antes de renovar
- ¿Qué parte de la recuperación de mis datos está cubierta por su servicio y qué parte me corresponde a mí, por escrito?
- ¿Dónde están físicamente mis datos, qué subcontratistas intervienen y qué cláusulas aplican para el cumplimiento de la Ley 1581 de 2012?
- ¿Existe una copia inmutable aislada del entorno de producción y de sus credenciales?
- ¿Cuándo fue la última restauración completa, qué tiempo tomó y puedo ver el informe?
- ¿Cómo y en cuánto tiempo puedo exportar mis estudios e informes en formato estándar si decido terminar el contrato?
Implicación práctica para gerencia, TI y archivo clínico
El primer entregable no es una compra, sino una tabla de servicios con su nivel, su RTO y su RPO firmada por los jefes de servicio. El segundo es una restauración de prueba con tiempos medidos. Con esos dos documentos, una institución puede evaluar objetivamente si su arquitectura, local, híbrida o en la nube, cumple lo que sus pacientes necesitan, y puede pedirle al proveedor evidencia en lugar de promesas.
Conozca las soluciones de Medilab Sistemas
Medilab Sistemas ofrece MEDIBACKUP CLOUD como respaldo en la nube para MediSystem PACS y MediClinic RIS, con arquitectura modular y soporte local en Bogotá. Si su institución necesita evaluar su capacidad real de recuperación, clasificar sus servicios por nivel y medir una restauración de prueba, el equipo de Medilab puede acompañar esa evaluación.
