CONDICIONES ESPECÍFICAS DE BACKUP, RESTAURACIÓN Y RECUPERACIÓN
Última actualización: 7 de agosto de 2026
Versión: 1.0
1. Objeto
Las presentes Condiciones regulan los servicios relacionados con:
copias de seguridad;
snapshots;
replicación;
conservación de copias;
restauración;
recuperación;
recuperación ante incidentes;
recuperación ante desastres;
pruebas de restauración;
RPO;
RTO;
conservación y eliminación de copias;
prestados por:
ACCION DIGITAL LOCAL S.L.
NIF: B75510008
Domicilio: Avinguda de les Glòries Catalanes, 62, Bloc B, Can Palet, 08223 Terrassa, Barcelona, España
Correo electrónico: info@acciondigital.es
en adelante, “ACCIÓN DIGITAL”.
2. Aplicación conjunta
Estas Condiciones complementan, cuando corresponda:
04 — Condiciones Generales;
05 — Sistemas y Automatización;
06 — Inteligencia Artificial;
07 — Hosting/VPS;
08 — SLA y Soporte;
09 — Seguridad y Responsabilidad Compartida;
11 — Acceptable Use Policy;
15 — DPA;
16 — SOW / Order Form;
17 — Offboarding.
3. Regla fundamental
La contratación de:
VPS;
hosting;
mantenimiento;
desarrollo;
soporte;
monitorización;
administración;
no implica automáticamente la contratación de un servicio gestionado de backup.
Solo existirán obligaciones específicas de backup cuando:
estén expresamente incluidas en la Orden/SOW;
o sean necesarias para cumplir una obligación legal o contractual aplicable a ACCIÓN DIGITAL.
4. Diferencia entre conceptos
A efectos contractuales:
| BACKUP ≠ SNAPSHOT SNAPSHOT ≠ BACKUP INDEPENDIENTE BACKUP ≠ REPLICACIÓN REPLICACIÓN ≠ BACKUP BACKUP ≠ ALTA DISPONIBILIDAD ALTA DISPONIBILIDAD ≠ DISASTER RECOVERY RPO ≠ RTO TENER BACKUP ≠ GARANTÍA DE RESTAURACIÓN INSTANTÁNEA |
|---|
Cada función responde a riesgos distintos.
5. Backup
Un Backup es una copia de determinados datos, configuraciones o sistemas destinada principalmente a permitir su recuperación posterior.
6. Snapshot
Un Snapshot representa el estado de un recurso en un momento determinado mediante las capacidades del sistema o proveedor correspondiente.
Puede depender de:
la misma infraestructura;
la misma cuenta;
el mismo proveedor;
el mismo almacenamiento lógico.
Por ello, un snapshot no debe presumirse equivalente a un backup independiente.
7. Replicación
La replicación mantiene copias adicionales de determinados datos o recursos.
Una eliminación, corrupción o actuación maliciosa puede propagarse también a una réplica.
Por ello:
replicación no equivale necesariamente a backup histórico.
8. Alta disponibilidad
La alta disponibilidad busca mantener un servicio funcionando ante determinados fallos.
No sustituye necesariamente las copias de seguridad.
9. Disaster Recovery
Un sistema de Disaster Recovery — DR comprende medidas destinadas a recuperar una operación después de un incidente grave o pérdida significativa de infraestructura.
Un plan formal de DR:
NO está incluido por defecto.
10. Alcance del backup
La Orden deberá identificar, cuando resulte relevante, qué elementos se copian.
Por ejemplo:
base de datos;
archivos;
volumen;
máquina virtual;
configuración;
repositorio;
aplicación;
documentos;
almacenamiento;
determinados secretos recuperables.
11. Elementos no incluidos automáticamente
Salvo contratación expresa, no se presumirá backup de:
cuentas de correo externas;
Google Workspace;
Microsoft 365;
Meta;
plataformas publicitarias;
CRM SaaS externo;
redes sociales;
cuentas de terceros;
dispositivos del CLIENTE;
servicios cloud no gestionados;
ordenadores locales;
contenido almacenado fuera del alcance identificado.
12. Matriz de backup
Cada servicio crítico debería poder documentarse mediante:
| ACTIVO QUÉ SE COPIA FRECUENCIA RETENCIÓN UBICACIÓN CIFRADO RESPONSABLE MÉTODO RPO RTO ÚLTIMO TEST DE RESTORE |
|---|
La información contractual específica podrá constar en el SOW o Anexo de Backup.
13. Frecuencia
La frecuencia de backup será la expresamente contratada.
Podrá ser, por ejemplo:
horaria;
diaria;
semanal;
mensual;
basada en eventos;
personalizada.
No se presumirá backup continuo.
14. Frecuencia frente a pérdida de datos
Si existe una copia cada 24 horas, puede existir riesgo de pérdida de los cambios realizados después de la última copia válida.
La frecuencia debe seleccionarse en función del riesgo aceptable.
15. RPO
Recovery Point Objective — RPO representa el objetivo relativo al punto temporal al que se pretende poder recuperar la información tras un incidente.
Ejemplo conceptual:
RPO 24h
puede implicar que el diseño acepta potencialmente perder cambios posteriores al último punto recuperable dentro de dicho objetivo.
16. RPO no implícito
No existirá un RPO contractual garantizado salvo que aparezca expresamente en:
Orden;
SOW;
plan de Backup;
DR Plan.
17. RTO
Recovery Time Objective — RTO representa el objetivo temporal de recuperación previsto para restablecer una función o servicio tras determinado incidente.
18. RTO no equivale a garantía
Salvo que se indique expresamente como compromiso contractual:
RTO = objetivo
y no necesariamente:
tiempo máximo garantizado.
19. RTO contractual
Cuando un RTO sea contractual, deberán definirse:
servicio afectado;
evento que inicia el cómputo;
dependencias;
horario;
exclusiones;
nivel de recuperación esperado.
20. RPO cero
No se presumirá un RPO 0.
Lograr una pérdida teórica cercana a cero puede requerir:
replicación;
journaling;
alta disponibilidad;
sistemas distribuidos;
arquitectura específica.
21. RTO inmediato
No se presumirá recuperación inmediata o “instantánea”.
La recuperación puede requerir:
aprovisionar recursos;
descargar datos;
restaurar;
reconstruir;
comprobar;
actualizar DNS;
verificar integridad;
realizar pruebas.
22. Retención
La Orden deberá definir, cuando resulte relevante, cuánto tiempo se mantienen las copias.
Podrán existir esquemas como:
últimas X copias;
X días;
X semanas;
X meses;
combinación de periodos.
23. Retención no indefinida
Las copias de seguridad no se conservarán indefinidamente salvo obligación o contratación específica.
Una copia podrá eliminarse automáticamente al superar su periodo de retención.
24. Rotación
Las copias podrán estar sujetas a sistemas automáticos de rotación.
Una copia antigua puede dejar de estar disponible sin intervención manual cuando alcance su fecha de expiración.
25. Copias múltiples
Cuando el nivel de protección lo requiera, podrán utilizarse varias copias o generaciones.
Esta medida deberá formar parte del plan contratado.
26. Separación lógica
Un backup podrá almacenarse en un recurso lógico distinto de producción.
La separación lógica no implica necesariamente separación:
física;
geográfica;
de proveedor.
27. Backup externo
Un backup externo puede almacenarse fuera del servidor principal.
Esto reduce determinados riesgos, pero no implica automáticamente utilización de otro proveedor o región.
28. Backup offsite
Cuando se contrate específicamente, podrán mantenerse copias en una ubicación distinta de la infraestructura principal.
29. Backup cross-provider
Una copia alojada en un proveedor distinto solo existirá cuando esté expresamente diseñada y contratada.
30. Riesgo de proveedor único
Cuando producción y backups dependan del mismo proveedor, podrán existir riesgos comunes relacionados con:
cuenta;
proveedor;
región;
plataforma;
error administrativo.
El CLIENTE podrá contratar una arquitectura adicional destinada a reducir dicho riesgo.
31. Regla 3-2-1
ACCIÓN DIGITAL podrá utilizar estrategias de múltiples copias, tecnologías o ubicaciones cuando resulten adecuadas al riesgo.
La denominada estrategia “3-2-1” u otra arquitectura equivalente no se considerará incluida por defecto salvo que figure en el diseño contratado.
32. Copias completas
Un backup podrá ser:
completo;
incremental;
diferencial;
snapshot;
lógico;
físico.
La técnica dependerá del sistema.
33. Backup de base de datos
Las bases de datos podrán requerir mecanismos propios para garantizar una copia coherente.
Copiar únicamente los archivos subyacentes de una base de datos activa no constituye necesariamente una copia válida de aplicación.
34. Consistencia
Dependiendo del sistema, una copia podrá ser:
crash-consistent;
filesystem-consistent;
application-consistent.
El nivel garantizado deberá definirse cuando resulte crítico.
35. Backup de aplicaciones
Una recuperación funcional puede necesitar más que los datos.
Por ejemplo:
aplicación;
versión;
configuración;
dependencias;
secretos;
DNS;
certificados;
base de datos;
archivos.
36. Configuración
Cuando resulte necesario, podrán incluirse copias o mecanismos de reconstrucción de:
configuración;
infraestructura como código;
contenedores;
manifests;
variables no secretas.
37. Secrets
Los secretos requieren tratamiento específico.
No todos los secrets podrán o deberán formar parte de una copia ordinaria.
38. Pérdida de secretos
Si un sistema depende de:
private key;
recovery key;
clave maestra;
y ésta no dispone de método válido de recuperación, los backups pueden resultar insuficientes para restaurar el servicio.
39. Custodia de claves
Cuando corresponda, el SOW deberá definir qué Parte custodia:
claves maestras;
recovery codes;
claves de cifrado;
credenciales críticas.
40. Clave maestra offline
Cuando la arquitectura incorpore una clave maestra o mecanismo de recuperación offline, su custodia deberá asignarse expresamente.
ACCIÓN DIGITAL no responderá automáticamente por la pérdida de una clave cuya custodia corresponda contractualmente al CLIENTE.
41. Cifrado de backups
Los backups podrán utilizar cifrado:
en tránsito;
en reposo;
cuando corresponda según arquitectura, proveedor y riesgo.
No se presumirá un mecanismo específico sin verificar la configuración real.
42. Gestión de claves de backup
Si las copias están cifradas, deberá existir un mecanismo adecuado de gestión y recuperación de las claves.
Cifrar una copia sin conservar correctamente la clave puede hacerla inutilizable.
43. Integridad
ACCIÓN DIGITAL podrá utilizar mecanismos destinados a comprobar razonablemente:
finalización;
tamaño;
hash;
errores;
estado;
según las capacidades del sistema.
44. Backup finalizado no equivale a restauración validada
Que una herramienta muestre:
BACKUP SUCCESS
no demuestra necesariamente que:
todos los datos esperados estén presentes;
la aplicación pueda arrancar;
todos los ficheros sean utilizables;
la restauración completa funcione.
45. Pruebas de restauración
Las pruebas de restore constituyen una medida distinta de la creación del backup.
Solo estarán incluidas con la frecuencia definida contractualmente.
46. Restore test
Un test podrá comprobar:
acceso a la copia;
descifrado;
extracción;
restauración;
arranque;
integridad;
funcionalidad mínima.
47. Frecuencia de test
Podrá establecerse, según riesgo:
mensual;
trimestral;
semestral;
anual;
después de cambios significativos;
según plan específico.
No existe una frecuencia única aplicable a todos los sistemas.
48. Prueba parcial
Una prueba de restauración de una parte del sistema no demuestra necesariamente la capacidad de recuperar toda la infraestructura.
49. Evidencia de test
Cuando esté incluida, ACCIÓN DIGITAL podrá conservar evidencia como:
| FECHA ACTIVO BACKUP UTILIZADO RESULTADO TIEMPO ERROR VERIFICACIÓN RESPONSABLE |
|---|
50. Fallo de prueba
Si una prueba detecta un problema, ACCIÓN DIGITAL podrá:
investigar;
corregir;
generar nueva copia;
modificar el procedimiento;
informar al CLIENTE cuando el impacto sea relevante.
51. Restauración
Una restauración podrá ser necesaria por:
eliminación accidental;
corrupción;
fallo;
malware;
error humano;
actualización defectuosa;
incidente de infraestructura.
52. Solicitud de restore
Cuando no exista una emergencia, el CLIENTE deberá indicar:
activo;
punto temporal;
motivo;
alcance;
prioridad.
53. Aprobación
Una restauración que pueda sobrescribir datos existentes podrá requerir aprobación del CLIENTE.
54. Restauración destructiva
Cuando restaurar una copia implique sustituir información más reciente, ACCIÓN DIGITAL procurará advertir de:
pérdida potencial;
fecha de la copia;
alcance;
consecuencias.
55. Restore alternativo
Cuando sea técnicamente posible, podrá restaurarse primero en un entorno separado para:
verificar;
extraer datos;
comparar;
reducir riesgo.
Esta actuación podrá implicar recursos y costes adicionales.
56. Restauración granular
No todos los sistemas permiten recuperar:
un único email;
un único registro;
un único archivo;
un único usuario.
La granularidad depende del mecanismo de backup.
57. Full restore
Una copia de servidor completo puede requerir restauración completa aun cuando el CLIENTE solo necesite un elemento individual.
58. Restore como servicio
El número de restauraciones incluidas dependerá del plan.
Salvo que el SOW indique lo contrario, una intervención extraordinaria de restore podrá ser facturable.
59. Emergencias
Ante una emergencia crítica, ACCIÓN DIGITAL podrá iniciar actuaciones de recuperación dentro de las autorizaciones previas existentes.
60. Preservación de evidencia
En incidentes de seguridad puede ser conveniente preservar una copia o snapshot antes de restaurar.
La prioridad no será necesariamente restaurar inmediatamente si ello pudiera destruir evidencia crítica.
61. Ransomware
El ransomware puede afectar:
producción;
almacenamiento montado;
backups accesibles;
credenciales;
cuentas cloud.
62. Protección frente a ransomware
Cuando el riesgo lo justifique podrán utilizarse medidas como:
separación;
inmutabilidad;
cuentas independientes;
control de acceso;
retención protegida.
Estas medidas no se consideran incluidas automáticamente.
63. Backup inmutable
Un backup immutable solo estará garantizado cuando el proveedor y configuración utilizados impidan o limiten técnicamente modificaciones durante el periodo correspondiente.
64. Administrador comprometido
Una cuenta administrativa comprometida puede permitir a un atacante intentar eliminar:
producción;
snapshots;
backups;
claves.
La arquitectura deberá considerar este riesgo cuando la criticidad lo justifique.
65. Separación de credenciales
Cuando proceda, podrán utilizarse credenciales distintas para:
producción;
backup;
recuperación.
66. Eliminación accidental
Una eliminación realizada por un usuario autorizado puede propagarse antes de detectarse.
La posibilidad de recuperación dependerá de:
frecuencia;
retención;
mecanismo;
momento de detección.
67. Corrupción silenciosa
Un dato puede corromperse y permanecer sin detectarse durante un periodo.
Si la corrupción es anterior a todas las copias conservadas, las copias disponibles pueden contener también el error.
68. Retención y corrupción
Una retención más larga puede aumentar la posibilidad de disponer de un punto anterior a una corrupción no detectada.
También puede aumentar:
almacenamiento;
costes;
exposición de datos.
La política deberá equilibrar ambos factores.
69. Error lógico
Un backup no corrige automáticamente errores como:
información incorrecta introducida;
factura errónea;
workflow equivocado;
cambios válidos pero no deseados.
70. Backup no sustituye controles operativos
Las copias no sustituyen:
permisos;
validación;
control de cambios;
aprobación;
seguridad.
71. Datos del CLIENTE
El CLIENTE deberá identificar cuando determinadas cargas tengan requisitos especiales de:
retención;
recuperación;
regulación;
continuidad.
72. Datos críticos
Si el CLIENTE considera determinados datos críticos para su negocio, deberá comunicarlo antes de contratar o configurar el plan de Backup.
73. Responsabilidad sobre clasificación
ACCIÓN DIGITAL no puede dimensionar correctamente una estrategia de recuperación si el CLIENTE no comunica requisitos materiales que solo él conoce.
74. SaaS de terceros
Que un SaaS externo diga disponer de backups propios no significa necesariamente que el CLIENTE pueda realizar una restauración granular bajo demanda.
Las capacidades del proveedor deberán revisarse.
75. Backup de SaaS
Cuando el CLIENTE necesite copias independientes de:
correo;
CRM;
documentos;
SaaS;
deberá contratar un mecanismo específico cuando sea técnicamente posible.
76. Backups del proveedor upstream
Los backups incluidos por un proveedor cloud estarán sujetos a:
sus capacidades;
condiciones;
retención;
disponibilidad.
77. Backup upstream ≠ obligación AD
La existencia de una funcionalidad de backup upstream no implica que ACCIÓN DIGITAL la haya activado, configurado, supervisado o probado.
Debe constar en el Servicio contratado.
78. Fallo del proveedor
ACCIÓN DIGITAL no controla completamente el funcionamiento interno del proveedor de backup.
Cuando exista un fallo upstream:
investigará;
escalará;
aplicará medidas razonables;
conforme al alcance contratado.
79. Monitorización de backups
Cuando esté contratada, ACCIÓN DIGITAL podrá monitorizar:
ejecución;
errores;
estado;
capacidad;
expiración.
80. Monitorización ≠ verificación absoluta
La ausencia de alerta no garantiza que una copia contenga todos los datos esperados.
81. Alertas
Un error de backup podrá generar alertas según las capacidades y configuración del sistema.
La recepción humana inmediata dependerá del SLA contratado.
82. Fallo de backup
Cuando se detecte un backup fallido, ACCIÓN DIGITAL podrá:
1. investigar;
2. reintentar;
3. corregir;
4. generar nueva copia;
5. escalar al proveedor.
83. Ventana sin copia válida
Un fallo puede aumentar temporalmente la distancia respecto del último punto recuperable válido.
Cuando sea relevante se evaluará el impacto sobre el RPO contratado.
84. Capacidad
La falta de almacenamiento puede impedir completar backups.
Cuando ACCIÓN DIGITAL gestione la capacidad podrá recomendar o ejecutar ampliaciones según el contrato.
85. Consumo y coste
Los backups pueden generar costes por:
almacenamiento;
operaciones;
tráfico;
egress;
snapshots;
restauración;
regiones;
proveedores.
86. Crecimiento de backup
El volumen de copias puede aumentar por:
crecimiento de datos;
mayor retención;
mayor frecuencia;
nuevas cargas.
Los costes podrán ajustarse conforme al contrato.
87. Retención legal
Cuando exista una obligación legal específica de conservación, deberá analizarse qué información debe conservarse y mediante qué sistema.
Un backup operativo no debe utilizarse automáticamente como archivo legal de largo plazo.
88. Backup ≠ archivo
Una copia diseñada para recuperación técnica no constituye necesariamente un sistema adecuado de:
archivo;
conservación probatoria;
records management.
89. Datos personales
Los backups pueden contener datos personales.
Cuando así sea, estarán sujetos al marco aplicable de protección de datos.
90. Minimización
La existencia de backups no autoriza a conservar indefinidamente datos personales sin finalidad.
91. Supresión y backups
Cuando un dato sea eliminado del sistema activo, puede permanecer temporalmente en copias de seguridad hasta completar su ciclo normal de retención.
92. Datos eliminados dentro del backup
Mientras permanezcan únicamente dentro de una copia protegida:
no deberán reutilizarse ordinariamente;
permanecerán sometidos a medidas de seguridad;
expirarán conforme al ciclo correspondiente, salvo obligación distinta.
93. Restauración de datos previamente suprimidos
Si una restauración técnica reintroduce datos que previamente debían estar eliminados, podrán ser necesarios procesos posteriores de reconciliación o nueva supresión.
94. Derecho de supresión
El hecho de que existan copias de seguridad no debe utilizarse como mecanismo para mantener de forma activa información cuya supresión proceda legalmente.
95. DPA
Cuando ACCIÓN DIGITAL trate los datos como encargado, las condiciones sobre:
devolución;
eliminación;
conservación;
subencargados;
se regularán adicionalmente mediante el DPA.
96. Seguridad
Los backups estarán incluidos dentro del modelo de responsabilidad de:
09 — Seguridad y Responsabilidad Compartida.
97. Acceso
El acceso a backups deberá limitarse a personas y sistemas autorizados.
98. Menor privilegio
Cuando sea razonablemente viable, los usuarios ordinarios de producción no deberán disponer de permisos administrativos sobre backups protegidos.
99. Logs
Podrán registrarse eventos como:
creación;
eliminación;
restore;
error;
modificación de política.
100. Restore por personal autorizado
Las restauraciones críticas deberán ser ejecutadas o autorizadas por personal con permisos adecuados.
101. Disaster Recovery Plan
Cuando se contrate un DR Plan, éste podrá documentar:
escenarios;
prioridades;
sistemas críticos;
responsables;
dependencias;
RTO;
RPO;
contactos;
procedimientos;
validación.
102. DR no genérico
Un Disaster Recovery Plan debe corresponder a la arquitectura real.
Un documento genérico sin pruebas no constituye garantía efectiva de recuperación.
103. Orden de recuperación
Cuando existan varios sistemas podrá establecerse un orden.
Ejemplo:
| P0 IDENTIDAD / ACCESOS P1 BASE DE DATOS CRÍTICA P2 APLICACIÓN PRINCIPAL P3 AUTOMATIZACIONES P4 SERVICIOS SECUNDARIOS |
|---|
104. Dependencias
La recuperación puede depender de:
DNS;
proveedor;
claves;
dominios;
APIs;
software;
terceros;
conectividad.
105. Dependencias no recuperables por backup
Un backup propio no permite necesariamente restaurar un servicio externo que haya dejado de existir.
106. Reconstrucción
Cuando el servidor original no sea confiable, podrá optarse por:
reconstrucción limpia + restauración de datos
en lugar de recuperar la máquina comprometida.
107. Infraestructura reproducible
Cuando esté incluida, disponer de:
scripts;
imágenes;
infraestructura como código;
configuración versionada;
puede reducir la dependencia de una copia completa de servidor.
108. Golden image
Una imagen base puede acelerar una reconstrucción.
No sustituye necesariamente los backups de datos actualizados.
109. Orden de reconstrucción
El proceso podrá ser:
| INFRAESTRUCTURA LIMPIA → CONFIGURACIÓN → SOFTWARE → DATOS → SECRETOS → VALIDACIÓN → PRODUCCIÓN |
|---|
110. Prueba de desastre
Una prueba completa de DR no está incluida por defecto.
Puede implicar recursos, tiempo y riesgo operativo adicionales.
111. Simulacros
Cuando se contraten, podrán realizarse:
tabletop exercises;
restores parciales;
reconstrucciones;
failover tests;
pruebas completas.
112. Resultado de prueba
Una prueba exitosa demuestra únicamente que el escenario probado funcionó bajo las condiciones de dicha prueba.
No elimina todos los riesgos futuros.
113. Recuperación parcial
En un desastre podrá priorizarse restaurar primero una funcionalidad mínima viable.
114. Servicio degradado
El servicio podrá considerarse recuperado operacionalmente aunque determinadas funciones secundarias permanezcan temporalmente indisponibles, dependiendo del objetivo definido.
115. Incidente de seguridad
Una restauración no sustituye el análisis de causa cuando exista posibilidad de:
malware;
intrusión;
credencial comprometida.
Restaurar sin corregir la causa puede provocar una nueva afectación.
116. Backup infectado
Una copia puede contener:
malware;
vulnerabilidad;
configuración comprometida;
datos ya alterados.
Por tanto, no toda copia histórica es automáticamente segura para producción.
117. Punto de restauración seguro
Durante un incidente puede ser necesario determinar qué copia es anterior al compromiso.
Esto puede aumentar el tiempo de recuperación.
118. Forense
Un análisis forense formal no se considera incluido en un servicio ordinario de backup.
119. Notificación
Cuando un incidente de disponibilidad constituya también una violación de seguridad de datos personales, se aplicarán adicionalmente los procedimientos del DPA y normativa correspondiente.
120. Eliminación deliberada
El CLIENTE no deberá eliminar deliberadamente backups administrados por ACCIÓN DIGITAL fuera del procedimiento acordado.
121. Acceso del CLIENTE
Cuando el CLIENTE disponga de permisos para borrar copias, asumirá el riesgo directamente relacionado con dichas actuaciones.
122. Cambios de política
El CLIENTE no deberá modificar sin coordinación:
frecuencia;
retención;
destino;
cifrado;
credenciales;
jobs;
de un sistema de backup gestionado por ACCIÓN DIGITAL.
123. Terceros del CLIENTE
Cuando un proveedor contratado por el CLIENTE modifique la política de Backup, el CLIENTE deberá comunicarlo.
124. Responsabilidad del CLIENTE
Corresponde al CLIENTE:
informar qué datos son críticos;
comunicar requisitos de recuperación;
conservar credenciales bajo su custodia;
aprobar restores destructivos;
mantener copias propias cuando haya asumido dicha obligación;
no modificar sistemas gestionados sin coordinación.
125. Responsabilidad de ACCIÓN DIGITAL
Cuando exista backup gestionado, ACCIÓN DIGITAL será responsable de ejecutar las obligaciones expresamente asumidas relacionadas con:
configuración;
programación;
supervisión;
retención;
restore;
pruebas;
según el plan contratado.
126. Responsabilidad upstream
El proveedor upstream responderá de aquellas funciones propias de su plataforma conforme a la relación contractual correspondiente.
127. Causa efectiva
La existencia de una pérdida de datos no determina automáticamente qué Parte es responsable.
Deberá analizarse:
causa;
política contratada;
último backup válido;
cambios;
actuación del CLIENTE;
actuación de terceros;
obligaciones asumidas.
128. Riesgo aceptado
Cuando el CLIENTE elija expresamente una política menos robusta después de recibir información suficiente sobre sus consecuencias, dicha decisión deberá tenerse en cuenta para valorar responsabilidades directamente relacionadas con ese riesgo.
129. Ejemplo de riesgo aceptado
Por ejemplo:
| OPCIÓN RECOMENDADA Backup diario + copia externa + 30 días OPCIÓN ELEGIDA POR CLIENTE Backup diario local + 7 días RIESGO ACEPTADO Menor histórico y dependencia del mismo proveedor |
|---|
130. Exclusiones de responsabilidad
Dentro de los límites legales, ACCIÓN DIGITAL no responderá automáticamente de imposibilidad de recuperar información cuando ésta se derive directamente de:
datos que nunca estuvieron incluidos en el backup contratado;
periodo anterior a la retención;
pérdida de clave bajo custodia del CLIENTE;
eliminación deliberada por el CLIENTE;
modificación no autorizada;
servicios externos no incluidos;
datos ya corruptos antes de la primera copia disponible.
131. No garantía de recuperación total
Salvo garantía contractual específica, no puede afirmarse que cualquier incidente permitirá siempre una recuperación:
completa;
sin pérdida;
inmediata;
idéntica al estado anterior.
132. Estándar profesional
ACCIÓN DIGITAL deberá ejecutar las funciones asumidas con diligencia profesional y adoptar medidas razonables de acuerdo con el plan y riesgo contratado.
133. Limitación económica
Será aplicable el régimen de limitación de responsabilidad previsto en:
04 — Condiciones Generales de Servicios Tecnológicos
salvo que una norma imperativa o acuerdo específico establezca otra cosa.
134. SLA
Los tiempos de soporte relacionados con una restauración se regirán por:
08 — SLA y Soporte.
El SLA de primera respuesta no equivale automáticamente al RTO.
135. Backup y disponibilidad
La existencia de backups no modifica automáticamente el porcentaje de disponibilidad contractual.
136. Fin del Servicio
Cuando termine un Servicio, deberán aplicarse las condiciones de:
17 — Offboarding.
137. Exportación previa
El CLIENTE deberá realizar o solicitar dentro del periodo aplicable cualquier exportación que necesite antes de la eliminación definitiva.
138. Periodo post-terminación
La disponibilidad de backups después de finalizar el Servicio dependerá de:
plan;
ciclo de retención;
DPA;
Offboarding;
obligaciones legales.
139. No acceso indefinido
El CLIENTE no deberá asumir que podrá solicitar una restauración meses después de cancelar el servicio si todas las copias han expirado conforme a la política aplicable.
140. Eliminación
Una vez vencidos los periodos correspondientes, las copias podrán eliminarse mediante los mecanismos normales de la plataforma.
141. Backups de proveedor
ACCIÓN DIGITAL puede no controlar el momento físico exacto en el que bloques subyacentes son sobrescritos o destruidos por un proveedor cloud.
142. Eliminación lógica
Cuando la infraestructura sea virtualizada, la eliminación podrá realizarse mediante mecanismos lógicos proporcionados por el proveedor.
143. Legal hold
Cuando exista una obligación válida de preservar determinada información, ACCIÓN DIGITAL podrá suspender la eliminación de las copias afectadas en la medida necesaria.
144. Portabilidad
La exportación y transferencia durante cambio de proveedor se regularán además mediante:
07 — Hosting/VPS;
17 — Offboarding;
y la normativa imperativa aplicable.
145. Documentación
Cuando esté incluida, ACCIÓN DIGITAL podrá mantener un Backup Register con información sobre los sistemas protegidos.
146. Backup Register
Podrá incluir:
| CLIENTE ACTIVO MÉTODO DESTINO FRECUENCIA RETENCIÓN ÚLTIMO SUCCESS ÚLTIMO RESTORE TEST RPO RTO RESPONSABLE ESTADO |
|---|
147. Control de cambios
Los cambios relevantes en una política de Backup deberán documentarse cuando afecten:
frecuencia;
retención;
ubicación;
método;
RPO;
RTO;
seguridad.
148. Cambio de proveedor
Si se cambia el proveedor de Backup, ACCIÓN DIGITAL deberá evaluar cuando corresponda:
migración;
retención;
compatibilidad;
seguridad;
tratamiento de datos.
149. Copias antiguas
No se trasladarán necesariamente todas las generaciones históricas al nuevo proveedor salvo contratación o necesidad específica.
150. Protección de datos
Cuando las copias contengan datos personales, serán aplicables:
Política de Privacidad;
DPA;
relación de Subencargados;
medidas de Seguridad.
151. Medidas proporcionales
La arquitectura de Backup deberá guardar relación con:
probabilidad de pérdida;
impacto;
sensibilidad;
criticidad;
capacidad económica;
requisitos legales.
152. Servicio crítico
Un sistema cuya interrupción pueda detener materialmente la actividad del CLIENTE debería disponer de una estrategia de recuperación explícitamente definida.
La mera existencia de un backup genérico puede resultar insuficiente.
153. Revisión periódica
Los requisitos de backup deberán revisarse cuando cambie:
volumen;
arquitectura;
criticidad;
regulación;
proveedor;
sistemas.
154. Modificaciones
Las modificaciones de estas Condiciones se regirán por las Condiciones Generales.
155. Legislación aplicable
Será aplicable la legislación establecida en las Condiciones Generales y, cuando existan datos personales, la normativa europea y española de protección de datos correspondiente.
156. Contacto
ACCION DIGITAL LOCAL S.L.
NIF B75510008
Avinguda de les Glòries Catalanes, 62, Bloc B, Can Palet
08223 Terrassa, Barcelona
España
Email: info@acciondigital.es
Versión: 1.0
Fecha: 7 de agosto de 2026