La adopción de una plataforma SaaS simplifica la infraestructura, las actualizaciones y el acceso, pero puede crear una suposición peligrosa: si el servicio está en la nube, entonces los datos están protegidos automáticamente. En los backups en plataformas SaaS, la disponibilidad, la redundancia y la copia de seguridad están relacionadas, pero no son equivalentes.
Un proveedor puede mantener la aplicación disponible ante la avería de un componente y, aun así, no ofrecer al cliente la restauración granular de un documento eliminado. Del mismo modo, puede replicar datos entre ubicaciones y propagar rápidamente una corrupción o una eliminación. También puede conservar copias técnicas para recuperar toda la plataforma, pero no poner a disposición del cliente un punto de recuperación individual.
Por eso, la pregunta “¿hacen backups?” es demasiado vaga. Una respuesta útil tiene que identificar qué se copia, qué incidentes están cubiertos, cuánto se puede perder, en cuánto tiempo se recupera, quién decide y qué prueba existe.
Un backup no es lo mismo que la sincronización, el historial o la alta disponibilidad
Backup: Copia separada que permite recuperar datos de un punto anterior tras una pérdida, corrupción o incidente.
Sincronización: Mantiene la información coherente entre ubicaciones o sistemas; puede propagar una eliminación o un error.
Historial de versiones: Permite recuperar versiones anteriores dentro de la aplicación, según sus propias reglas y plazos.
Replicación: Copia los cambios a otro entorno para garantizar la disponibilidad; no siempre conserva estados antiguos.
Exportación: Entrega los datos al cliente en un formato definido; puede facilitar la portabilidad, pero no sustituye la recuperación operativa.
Alta disponibilidad: Reduce las interrupciones del servicio ante fallos; no resuelve necesariamente la pérdida lógica de datos.
Regla práctica: Si el mecanismo no permite volver a un estado anterior, aislado del incidente, y restaurar datos utilizables, no debe tratarse como backup solo porque existan varias copias.
Antes de las 12 preguntas: Convierta las respuestas en compromisos
Las respuestas comerciales como “backup diario”, “redundancia geográfica” o “cumplimos las mejores prácticas” no bastan para gestionar el riesgo. Por eso, busque cuatro cualidades: lenguaje contractual, métricas medibles, responsabilidades asignadas y evidencia verificable.
Contractual: la respuesta debe figurar en el contrato, el SLA, el anexo de seguridad o la documentación vinculante aplicable.
Medible: la frecuencia, la retención, el RPO, el RTO, la cobertura y los plazos no deben depender de interpretaciones.
Operativa: el proceso debe indicar la solicitud, la aprobación, la escalada, la comunicación, el coste y los criterios de cierre.
Demostrable: informes, pruebas, registros, certificaciones o evidencias equivalentes deben respaldar la afirmación.
12 preguntas sobre backups en plataformas SaaS
1. ¿Qué datos, metadatos y configuraciones se incluyen?
Confirme si la copia abarca documentos, versiones, metadatos, comentarios, decisiones de validación, anexos, usuarios, permisos, logs de auditoría, reglas, flujos y configuraciones necesarias para reconstruir el proceso. En efecto, recuperar solo los archivos puede dejar la información sin contexto, titularidad ni valor probatorio.
Pida una lista de inclusiones y exclusiones. Por ejemplo, las integraciones, los archivos temporales, los datos de aplicaciones conectadas y las claves pueden tener políticas diferentes.
2. ¿Qué escenarios de pérdida están realmente cubiertos?
Contraste la respuesta con situaciones concretas: eliminación accidental por parte de un usuario, modificación indebida, corrupción silenciosa, compromiso de una cuenta administrativa, ransomware, fallo de una región, indisponibilidad prolongada del proveedor y error en una actualización. Esto se debe a que el mismo diseño de backup puede no responder a todos estos escenarios.
3. ¿Las copias están separadas del entorno de producción?
Pregunte si existe separación de credenciales, cuentas, tenancies, regiones o entornos y si una cuenta comprometida en producción puede eliminar o cifrar las copias. La CISA recomienda backups offline o cloud-to-cloud, cifrados, probados y protegidos contra modificación o eliminación, además de revisar el modelo de responsabilidad compartida en la nube.
“Está en otro centro de datos” no responde a la cuestión de si los mismos privilegios, claves o comandos alcanzan ambos entornos.
Recuperación de backups en plataformas SaaS
4. ¿Cuál es el RPO para cada categoría de información?
El Recovery Point Objective indica la pérdida máxima de datos tolerada, expresada en tiempo. Si el RPO es de cuatro horas, una recuperación puede hacer que la organización retroceda hasta cuatro horas. Así, compare ese intervalo con el ritmo real de envíos, validaciones, accesos y cambios documentales.
Además, los datos con impactos diferentes pueden justificar objetivos diferentes. El NIST recomienda definir el RPO por activo y alinear la frecuencia y la tecnología de copia con ese objetivo.
5. ¿Cuál es el RTO y cuándo empieza a contar?
El Recovery Time Objective representa el tiempo previsto para restablecer el servicio o los datos. Aclare si el cómputo empieza con el incidente, la detección, la apertura de la solicitud o la confirmación del proveedor. Confirme también si el plazo cubre solo la entrega de archivos o la restauración funcional de la aplicación, incluidas configuraciones, permisos y dependencias.
Un RTO solo es creíble cuando se ha medido en una prueba comparable e incluye componentes como datos, aplicación, configuración y claves.
6. ¿Qué granularidad de restauración está disponible?
Compruebe si es posible recuperar un documento, una versión, un registro, una carpeta lógica, un contratista, una unidad, una base de datos o todo el entorno. Sin embargo, cuanto más amplia sea la restauración, mayor puede ser el impacto sobre los cambios legítimos realizados después del punto elegido.
Pregunte también cómo se concilian los datos recuperados con el estado actual y cómo se evita reintroducir información corrupta o código comprometido.
Retención, protección y pruebas
7. ¿Durante cuánto tiempo están disponibles los puntos de recuperación?
La retención debe ser lo bastante larga para detectar incidentes tardíos, pero no puede confundirse con una conservación indefinida. Pida la secuencia real de puntos disponibles: diarios, semanales, mensuales u otro modelo, y confirme qué ocurre cuando el cliente elimina datos por obligación o por política.
Distinguir la retención del backup, la retención documental y el archivo evita que una copia técnica se utilice como sustituto de una política de conservación aprobada.
8. ¿Cómo protege el proveedor los accesos, las claves y las ubicaciones?
Confirme el cifrado en tránsito y en reposo, la gestión y recuperación de claves, la autenticación robusta, el mínimo privilegio, la separación de funciones, el registro de accesos y la protección contra la eliminación. Además, pregunte dónde trata y almacena los datos el proveedor, qué subencargados intervienen y cómo controla las transferencias internacionales.
Una copia cifrada es inútil si la organización no puede acceder a la clave durante la recuperación; y es insegura si la clave puede verse comprometida por la misma vía que la producción.
9. ¿Cuándo se realizó la última prueba y qué evidencia existe?
Pida la fecha, el alcance, el escenario, el volumen, el resultado, el RPO y el RTO observados, los fallos encontrados y las acciones correctivas. Una prueba con un archivo pequeño no demuestra que una base de datos, un historial o un entorno completo puedan recuperarse dentro del plazo que exige el negocio.
El RGPD incluye la capacidad de restablecer la disponibilidad y el acceso de forma rápida y un proceso de verificación y evaluación regulares de las medidas de seguridad. El responsable competente debe validar su aplicación concreta.
Responsabilidades y salida en los backups en plataformas SaaS
10. ¿Quién puede solicitar, aprobar y ejecutar una restauración?
Defina los contactos, la autenticación de la solicitud, la autoridad para decidir, las prioridades, la comunicación, la escalada, las ventanas de ejecución y los costes. Un proceso técnicamente posible puede fallar porque nadie sabe quién autoriza la recuperación o porque el contacto no está disponible fuera del horario habitual.
Por último, incluya la responsabilidad del cliente de clasificar los datos, definir objetivos, mantener los contactos y validar el resultado; y la del proveedor de ejecutar, comunicar y conservar la evidencia, conforme al servicio contratado.
11. ¿Cómo exportar los datos y preparar la salida?
El backup y la portabilidad no son lo mismo; sin embargo, una estrategia de salida reduce la dependencia. Confirme las categorías exportables, los formatos estructurados, los metadatos, los anexos, los logs, la documentación técnica, la frecuencia, la duración, el coste y la capacidad de importación en otro entorno.
El Reglamento de Datos de la Unión Europea contiene normas sobre el cambio de servicios de tratamiento de datos, la información sobre formatos, la continuidad y los periodos de recuperación. No obstante, profesionales jurídicos deben revisar la aplicabilidad y las cláusulas del contrato, teniendo en cuenta el tipo de servicio y las posibles excepciones.
12. ¿Qué ocurre con las copias al final del contrato?
El contrato debe explicar el periodo durante el cual se pueden recuperar los datos, el momento de la eliminación, el tratamiento de las copias residuales, la emisión de una confirmación, los casos de conservación obligatoria y el impacto de litigios o de un legal hold. Por eso, el cliente debe completar y validar la exportación antes de perder el acceso.
En el tratamiento de datos personales, las instrucciones, la devolución o la eliminación al término del servicio y las medidas de seguridad deben estar alineadas con las funciones y obligaciones aplicables al responsable y al encargado del tratamiento.
Tabla rápida de evaluación del proveedor
Cobertura
Evidencia esperada: Inventario de datos, metadatos, logs y configuraciones incluidos.
Señal de alerta: “Hacemos backup de todo” sin lista de exclusiones.
Recuperación
Evidencia esperada: RPO/RTO por servicio, granularidad y procedimiento.
Señal de alerta: Plazos solo orientativos o contados tras la aceptación interna.
Resiliencia
Evidencia esperada: Separación de entornos, inmutabilidad y control de eliminación.
Señal de alerta: Mismas credenciales administrativas en producción y en backup.
Pruebas
Evidencia esperada: Informe reciente, escenario comparable y acciones correctivas.
Señal de alerta: Prueba limitada a un archivo sin medición del tiempo.
Seguridad
Evidencia esperada: Cifrado, claves, accesos, registros, ubicaciones y subencargados.
Señal de alerta: Respuestas genéricas sin responsables ni evidencia.
Operación
Evidencia esperada: Contactos, aprobación, escalada, comunicación y costes.
Señal de alerta: Proceso dependiente de una persona o de un canal informal.
Salida
Evidencia esperada: Formatos, alcance, periodo de recuperación, soporte y eliminación.
Señal de alerta: Exportación sin metadatos o sin prueba de reutilización.
Defina objetivos a partir del impacto en el negocio
No elija el RPO y el RTO solo porque el proveedor ya los ofrece. Por el contrario, deben partir del impacto de la indisponibilidad y de la pérdida de cambios. Así, un análisis sencillo por proceso documental ayuda a evitar el mismo nivel de servicio para todo.
Autorizaciones de acceso
Impacto principal: Bloqueos o entradas indebidas.
Implicación para el backup: Baja tolerancia; recuperación prioritaria.
Validaciones y rechazos
Impacto principal: Pérdida de decisiones y retrabajo.
Implicación para el backup: Conservar el historial, los comentarios y los responsables.
Documentos legales/contractuales
Impacto principal: Falta de evidencia y riesgo en auditoría.
Implicación para el backup: Retención y recuperación alineadas con requisitos validados.
Configuración y permisos
Impacto principal: Proceso restablecido con reglas erróneas.
Implicación para el backup: Incluir en el alcance o mantener una reconstrucción documentada.
Contenido informativo
Impacto principal: Impacto operativo limitado.
Implicación para el backup: Objetivos proporcionales al valor y al coste.
Responsabilidad compartida: Cuatro decisiones que no debe delegar
Clasificar la criticidad de la información e identificar las dependencias del proceso.
Aprobar el RPO, el RTO, la retención y las prioridades de recuperación con los responsables de negocio.
Mantener los contactos, los procedimientos internos y la autoridad para solicitar y validar una restauración.
Probar la continuidad completa, incluidas personas, integraciones, accesos y comunicación, y no solo la copia técnica.
El proveedor controla la tecnología y ejecuta el servicio contratado; la organización, en cambio, sigue decidiendo qué es crítico, qué pérdida tolera y cuándo el resultado es aceptable. Por eso, esta frontera debe figurar en una matriz de responsabilidades sencilla y actualizada.
Plan de revisión en 30 días
Semana 1
Inventariar las plataformas SaaS e identificar propietarios, datos críticos, integraciones y contratos.
Semana 2
Enviar las 12 preguntas y reunir SLA, anexos de seguridad, informes de pruebas y documentación de salida.
Semana 3
Comparar las necesidades con el RPO/RTO, la cobertura y la retención; registrar carencias, responsables y riesgo aceptado.
Semana 4
Realizar u observar una prueba representativa; actualizar procedimientos, contactos, cláusulas y plan de mejora.
Preguntas frecuentes sobre backups en plataformas SaaS
¿El proveedor SaaS es siempre responsable del backup?
No debe presuponerse. El contrato y el modelo de responsabilidad compartida determinan el servicio prestado, mientras que la organización mantiene responsabilidades sobre la clasificación, los objetivos, los accesos, las instrucciones y la continuidad. Confírmelo por escrito.
¿La exportación periódica sustituye a un backup?
No necesariamente. Puede respaldar la soberanía y la salida, pero puede no conservar versiones, relaciones, permisos, logs ni la capacidad de restauración rápida. Por eso, conviene probarla como parte de una estrategia más amplia.
¿Cuál es un buen RPO o RTO?
No existe un valor universal. El objetivo adecuado depende del impacto de perder cambios y del tiempo máximo de interrupción tolerable para cada proceso.
¿Un backup inmutable resuelve el riesgo de ransomware?
Reduce la posibilidad de modificación o eliminación de la copia, pero no garantiza que la copia esté limpia, completa o sea recuperable, ni sustituye el control de accesos, la detección, la respuesta y las pruebas.
¿Es necesario hacer pruebas si el proveedor ya presenta certificaciones?
Sí. Las certificaciones pueden reforzar la confianza en el sistema de gestión y en los controles evaluados, pero no demuestran, por sí solas, que sus datos y dependencias se hayan recuperado en el plazo específico del negocio.
¿Qué áreas deben participar en la evaluación?
TI y seguridad, el propietario del proceso, compras, el área jurídica, protección de datos, continuidad y gestión documental. De este modo, se evita una decisión solo técnica o solo contractual.
De la evaluación a la operación documental
La calidad del backup depende también de cómo se administra la plataforma: propietarios identificados, accesos actualizados, configuraciones documentadas, cambios controlados y procedimientos conocidos. De hecho, una plataforma técnicamente robusta puede seguir siendo vulnerable a procesos informales o a responsabilidades ambiguas.
GEDOC Service trabaja en la digitalización, la parametrización, la administración técnica y el soporte al uso de plataformas de gestión documental, a partir de los procesos definidos por el cliente. Así, esta operación estructurada puede ayudar a mantener controlados la información de configuración, las responsabilidades y los procedimientos, sin sustituir la definición de los requisitos legales, de seguridad o de continuidad por parte de la organización y de los proveedores competentes.
Próximo paso: Elija una plataforma documental crítica y solicite respuestas documentadas a las 12 preguntas. Si el RPO, el RTO, la granularidad, las pruebas o la salida no pueden demostrarse, registre la carencia como riesgo y asigne una acción con plazo y responsable.
Conozca GEDOC Service y consulte los contenidos complementarios sobre validación de la recuperación y backup 3-2-1-1-0.
Artículos relacionados
Validación de la recuperación (Proof of Restore)
La importancia de los backups en la gestión documental
GEDOC Service, administración técnica de plataformas
Política de gestión del historial de los documentos
Nota editorial y fuentes consultadas
Este artículo es informativo y se dirige a organizaciones que evalúan servicios SaaS en Portugal y en la Unión Europea. No constituye asesoramiento jurídico, de ciberseguridad ni de continuidad, ni confirma las características de ningún proveedor. Profesionales competentes deben validar los requisitos, los contratos, los riesgos y las medidas.
Fuentes consultadas el 4 de agosto de 2026:
EUR-Lex, RGPD, artículos 28 y 32
EUR-Lex, Reglamento de Datos, capítulo VI
NIST SP 800-209, Security Guidelines for Storage Infrastructure
ENISA, Procure Secure: cloud security service levels
GEDOC, Backups, GEDOC Service y artículos relacionados
Para profundizar: Cómo elegir una plataforma de gestión documental.