Seguridad y Responsabilidad Compartida

CONDICIONES DE SEGURIDAD Y RESPONSABILIDAD COMPARTIDA

Última actualización: 7 de agosto de 2026

Versión: 1.0

1. Objeto

Las presentes Condiciones regulan la distribución de responsabilidades en materia de seguridad entre:

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”,

y la persona física o jurídica que contrate sus servicios, en adelante el “CLIENTE”.

Estas Condiciones establecen un modelo de responsabilidad compartida aplicable a sistemas, automatizaciones, infraestructura, hosting, VPS, aplicaciones, integraciones, inteligencia artificial y demás servicios tecnológicos gestionados total o parcialmente por ACCIÓN DIGITAL.

2. Principio de responsabilidad compartida

La seguridad de un sistema depende de múltiples capas.

La contratación de ACCIÓN DIGITAL no implica que ACCIÓN DIGITAL asuma automáticamente el control o responsabilidad de todos los elementos relacionados con:

infraestructura;

dispositivos;

usuarios;

cuentas;

redes;

aplicaciones;

datos;

proveedores;

permisos;

credenciales;

procesos del CLIENTE.

Cada Parte será responsable de los elementos que:

1. se encuentren bajo su control;

2. le hayan sido atribuidos contractualmente;

3. deba gestionar legalmente según su papel.

3. No existe seguridad absoluta

ACCIÓN DIGITAL aplicará medidas de seguridad razonables y proporcionadas al servicio contratado y al riesgo identificado.

No se garantiza que un sistema sea:

invulnerable;

imposible de atacar;

imposible de comprometer;

absolutamente libre de vulnerabilidades;

inmune a errores humanos;

inmune a vulnerabilidades desconocidas;

inmune a ataques de terceros.

La obligación de seguridad no deberá interpretarse como garantía de riesgo cero.

4. Seguridad basada en riesgo

Las medidas aplicables podrán variar atendiendo a:

naturaleza del Servicio;

datos tratados;

volumen;

sensibilidad;

número de usuarios;

exposición a Internet;

impacto potencial;

infraestructura;

arquitectura;

funcionalidades;

coste;

estado de la técnica;

obligaciones regulatorias.

No todos los sistemas requieren exactamente los mismos controles.

5. Evaluación inicial

ACCIÓN DIGITAL podrá solicitar información para evaluar:

finalidad del sistema;

información tratada;

usuarios;

accesos;

integraciones;

exposición pública;

criticidad;

requisitos regulatorios;

consecuencias de una interrupción;

consecuencias de una pérdida de datos.

La calidad de la evaluación dependerá de la información proporcionada por el CLIENTE.

6. Cambios de riesgo

El CLIENTE deberá informar cuando se produzcan cambios materiales como:

incorporación de datos sensibles;

nuevos usuarios;

nueva integración;

exposición pública;

acceso administrativo adicional;

cambio de finalidad;

incorporación de pagos;

aumento significativo de volumen;

nuevas jurisdicciones;

nuevas obligaciones regulatorias.

Un cambio relevante puede requerir nuevas medidas de seguridad.

7. Seguridad por diseño

Cuando ACCIÓN DIGITAL diseñe un sistema, procurará incorporar controles de seguridad desde su arquitectura cuando sean razonablemente necesarios.

Podrán incluir:

separación de componentes;

mínimo privilegio;

autenticación;

autorización;

gestión de secretos;

logs;

backups;

segmentación;

controles de entrada;

actualizaciones;

mecanismos de recuperación.

8. Seguridad por defecto

Cuando sea razonablemente viable, las configuraciones iniciales procurarán evitar:

permisos innecesarios;

servicios públicos innecesarios;

credenciales compartidas;

cuentas genéricas;

exposición de puertos innecesarios;

configuraciones manifiestamente inseguras.

9. Matriz de responsabilidad

Cada proyecto podrá disponer de una matriz específica:

CONTROL RESPONSABLE APOYO EVIDENCIA FRECUENCIA

El SOW podrá modificar la distribución general establecida en estas Condiciones.

10. Tres capas de responsabilidad

Podrán intervenir:

ACCIÓN DIGITAL

Responsable de los componentes que gestione contractualmente.

CLIENTE

Responsable de sus usuarios, decisiones, dispositivos, información y elementos bajo su control.

PROVEEDOR UPSTREAM

Responsable de los elementos asumidos directamente por el proveedor de infraestructura, cloud, SaaS, API u otro servicio externo.

11. Seguridad física

Cuando la infraestructura física pertenezca a un proveedor upstream, ACCIÓN DIGITAL no gestiona directamente:

edificio;

control físico;

suministro eléctrico;

hardware físico;

climatización;

seguridad física del datacenter.

Estas funciones corresponderán al proveedor correspondiente.

12. Identidades

Toda persona o sistema con acceso deberá utilizar, cuando sea razonablemente posible, una identidad identificable.

Se procurará evitar cuentas compartidas para funciones administrativas.

13. Alta de usuarios

El CLIENTE será responsable de determinar:

quién necesita acceso;

qué función tiene;

qué permisos necesita.

ACCIÓN DIGITAL podrá ejecutar técnicamente el alta cuando esté incluida en el Servicio.

14. Baja de usuarios

El CLIENTE deberá informar sin demora indebida cuando una persona:

deje la empresa;

cambie de función;

ya no necesite acceso;

deje de estar autorizada.

ACCIÓN DIGITAL no puede revocar oportunamente un usuario cuya baja no le haya sido comunicada cuando dicha información dependa del CLIENTE.

15. Revisión de usuarios

Cuando esté incluida, podrá realizarse una revisión periódica de:

usuarios activos;

cuentas privilegiadas;

cuentas de servicio;

accesos.

La periodicidad se determinará según el Servicio.

16. Principio de mínimo privilegio

Los usuarios y sistemas deberán disponer, cuando sea razonablemente viable, únicamente de los permisos necesarios para ejecutar sus funciones.

17. Separación de funciones

Cuando el riesgo lo justifique podrán separarse funciones como:

administración;

desarrollo;

aprobación;

auditoría;

facturación;

producción.

No todos los servicios incluyen separación completa de funciones.

18. Acceso privilegiado

Las cuentas con permisos elevados deberán recibir controles reforzados cuando sea técnicamente posible.

Podrán incluir:

MFA;

claves específicas;

acceso limitado;

registro;

restricciones de red;

cuentas nominativas.

19. Root y administrador

El acceso root o administrador implica capacidad para:

alterar seguridad;

eliminar información;

cambiar configuraciones;

modificar permisos;

detener servicios.

La concesión de acceso root al CLIENTE modifica materialmente el modelo de responsabilidad.

20. Responsabilidad con root del CLIENTE

Cuando el CLIENTE disponga de acceso root o administrador, será responsable de las actuaciones realizadas mediante dicho acceso por:

sus empleados;

sus proveedores;

sus cuentas;

sus credenciales;

salvo que pueda acreditarse otra causa.

21. MFA

Cuando esté técnicamente disponible y sea adecuado al riesgo, ACCIÓN DIGITAL podrá exigir autenticación multifactor para:

cuentas administrativas;

paneles críticos;

repositorios;

infraestructura;

herramientas empresariales.

22. Rechazo de MFA

Cuando ACCIÓN DIGITAL recomiende o exija razonablemente MFA y el CLIENTE decida no habilitarlo en un sistema bajo su control, dicho riesgo deberá documentarse cuando sea relevante.

23. Contraseñas

Las contraseñas deberán gestionarse con medidas razonables.

No deberán:

compartirse innecesariamente;

publicarse;

almacenarse en documentación pública;

reutilizarse deliberadamente en múltiples sistemas críticos cuando pueda evitarse.

24. Gestores de contraseñas

Podrá recomendarse o exigirse el uso de un mecanismo de gestión de credenciales adecuado al proyecto.

25. Secrets

Se consideran secretos, entre otros:

API keys;

tokens;

private keys;

contraseñas;

certificados privados;

códigos de recuperación;

claves maestras.

26. Gestión de secretos

Cuando resulte razonablemente viable, los secretos deberán almacenarse en:

gestores de secretos;

variables protegidas;

sistemas específicos de credenciales;

mecanismos equivalentes.

No deberán incluirse deliberadamente en repositorios públicos.

27. Credenciales en tickets

Los tickets no deberán utilizarse como repositorio permanente de contraseñas o secretos.

Cuando resulte necesario intercambiar un secreto se utilizará, cuando sea posible, un canal más adecuado.

28. Rotación

Las credenciales podrán rotarse cuando exista:

sospecha de compromiso;

cambio de personal;

terminación;

cambio de proveedor;

obligación de seguridad;

incidente.

29. Revocación

ACCIÓN DIGITAL podrá revocar temporalmente una credencial cuando exista una sospecha razonable de:

compromiso;

abuso;

acceso no autorizado;

exposición.

30. Credenciales del CLIENTE

El CLIENTE será responsable de la custodia de las credenciales que permanezcan bajo su control.

31. Credenciales de ACCIÓN DIGITAL

ACCIÓN DIGITAL será responsable de gestionar razonablemente las credenciales que controle directamente.

32. Machine identities

Cuando sea posible, las integraciones automatizadas utilizarán identidades técnicas independientes de cuentas personales.

33. API keys

Las API keys deberán limitarse, cuando el proveedor lo permita, según:

función;

permisos;

entorno;

consumo;

recurso.

34. Endpoints del CLIENTE

Salvo contratación específica, ACCIÓN DIGITAL no administra la seguridad de:

portátiles;

móviles;

ordenadores personales;

routers;

Wi-Fi;

dispositivos del CLIENTE.

35. Malware en dispositivo del CLIENTE

Un dispositivo comprometido puede permitir:

robo de sesión;

robo de contraseña;

acceso indebido;

extracción de datos.

Los incidentes originados directamente en dispositivos no gestionados por ACCIÓN DIGITAL no serán automáticamente imputables a ACCIÓN DIGITAL.

36. Red del CLIENTE

El CLIENTE será responsable de su:

conexión;

red local;

Wi-Fi;

router;

firewall local;

salvo que su gestión forme parte del Servicio.

37. Infraestructura gestionada

ACCIÓN DIGITAL será responsable de aplicar los controles contratados sobre la infraestructura que gestione directamente.

38. Patching

Cuando esté incluido en el Servicio gestionado, ACCIÓN DIGITAL podrá aplicar actualizaciones de seguridad sobre los componentes bajo su administración.

39. Componentes no gestionados

ACCIÓN DIGITAL no estará obligada a parchear automáticamente:

dispositivos del CLIENTE;

software instalado por terceros;

aplicaciones fuera de alcance;

infraestructura ajena;

salvo contratación específica.

40. Vulnerabilidades críticas

Cuando se detecte una vulnerabilidad crítica sobre un componente gestionado, ACCIÓN DIGITAL podrá adoptar medidas urgentes como:

actualizar;

limitar acceso;

desactivar funcionalidad;

aislar;

bloquear;

reiniciar.

41. Compatibilidad frente a seguridad

En determinadas situaciones, una actualización de seguridad puede producir incompatibilidades.

ACCIÓN DIGITAL procurará valorar:

riesgo de no parchear;

impacto del parche;

posibilidad de pruebas;

alternativas.

42. Software EOL

El software fuera de soporte puede representar un riesgo creciente.

ACCIÓN DIGITAL podrá:

recomendar actualización;

limitar soporte;

exigir migración;

suspender determinadas garantías;

cuando mantener el componente resulte inseguro.

43. Rechazo de actualización

Cuando el CLIENTE rechace una actualización recomendada por razones de seguridad, el riesgo asociado podrá documentarse.

ACCIÓN DIGITAL no responderá automáticamente de consecuencias directamente derivadas del riesgo que haya sido expresamente advertido y rechazado, dentro de los límites legales.

44. Gestión de vulnerabilidades

ACCIÓN DIGITAL podrá utilizar:

alertas de fabricantes;

análisis;

escáneres;

inventario;

revisión manual;

información de proveedores;

según el nivel contratado.

45. Escaneo de vulnerabilidades

Un escaneo automático no garantiza descubrir todas las vulnerabilidades.

46. Pentesting

Un test de penetración completo no está incluido por defecto.

Deberá contratarse expresamente.

47. Pruebas del CLIENTE

El CLIENTE no deberá ejecutar pruebas intrusivas contra infraestructura gestionada por ACCIÓN DIGITAL sin autorización previa.

48. Divulgación responsable

Las vulnerabilidades detectadas deberán comunicarse mediante el canal de seguridad establecido.

No deberán explotarse más allá de lo razonablemente necesario para identificar el problema.

49. Configuración segura

ACCIÓN DIGITAL podrá aplicar configuraciones orientadas a reducir superficie de ataque.

Podrán incluir:

desactivación de servicios;

restricción de puertos;

permisos limitados;

configuración de autenticación;

cabeceras;

controles de acceso.

50. Firewall

Cuando forme parte del Servicio, ACCIÓN DIGITAL podrá gestionar controles de red.

El firewall no constituye una garantía absoluta de protección.

51. Puertos

Los servicios no necesarios no deberían permanecer expuestos públicamente.

ACCIÓN DIGITAL podrá cerrar un puerto cuando exista riesgo.

52. Acceso remoto

El acceso administrativo podrá restringirse mediante:

VPN;

red privada;

allowlist;

túneles;

mecanismos similares.

La técnica concreta dependerá de la arquitectura.

53. Segmentación

Cuando el riesgo y arquitectura lo permitan, podrán separarse:

producción;

pruebas;

administración;

servicios internos;

clientes.

54. Aislamiento entre clientes

ACCIÓN DIGITAL adoptará medidas razonables para impedir que un CLIENTE pueda acceder a recursos de otro CLIENTE bajo su gestión.

55. Arquitectura dedicada

Cuando un CLIENTE disponga de infraestructura dedicada, dicha separación no implica necesariamente hardware físico dedicado salvo contratación expresa.

56. Cifrado en tránsito

Cuando sea técnicamente apropiado, las comunicaciones sensibles deberán utilizar protocolos cifrados.

57. Cifrado en reposo

El cifrado en reposo podrá aplicarse según:

proveedor;

sistema;

tipo de dato;

arquitectura;

riesgo.

No deberá presumirse que todos los componentes utilizan el mismo mecanismo.

58. Gestión de claves

Cuando exista cifrado controlado por claves específicas deberá determinarse quién es responsable de:

creación;

custodia;

backup;

rotación;

recuperación;

revocación.

59. Pérdida de claves

La pérdida de una clave de cifrado no recuperable puede impedir técnicamente la recuperación de los datos protegidos.

60. Datos

El CLIENTE será responsable de determinar qué información introduce en sus sistemas, salvo que la finalidad sea determinada conjuntamente de otra manera.

61. Clasificación de información

Cuando la criticidad lo requiera, podrán establecerse categorías como:

PÚBLICA INTERNA CONFIDENCIAL RESTRINGIDA

Las medidas podrán variar según clasificación.

62. Datos innecesarios

El CLIENTE deberá evitar introducir datos personales o información confidencial que no resulte necesaria para la finalidad del sistema.

63. Categorías especiales

Los sistemas que deban tratar categorías especiales de datos personales requerirán evaluación adicional.

64. Datos productivos en TEST

Se procurará evitar copiar indiscriminadamente datos reales de producción a entornos de desarrollo o prueba.

65. Sanitización

Cuando resulte razonable podrán utilizarse:

anonimización;

seudonimización;

datos sintéticos;

reducción de campos;

en entornos no productivos.

66. Backups

Las responsabilidades específicas sobre backups se regulan mediante:

10 — Backup y Recuperación.

67. Seguridad de backups

Cuando ACCIÓN DIGITAL gestione backups, procurará protegerlos mediante controles adecuados a la arquitectura.

68. Separación de backups

Cuando el plan lo contemple, podrán mantenerse copias separadas de la infraestructura principal.

No se presumirá esta medida si no forma parte del Servicio contratado.

69. Restauración

Disponer de un backup no garantiza que toda restauración sea:

instantánea;

completa;

libre de incompatibilidades.

70. Logs

Cuando esté previsto, los sistemas podrán registrar eventos para:

seguridad;

soporte;

auditoría;

diagnóstico;

trazabilidad.

71. Accesos registrados

Los sistemas críticos podrán registrar, cuando técnicamente sea viable:

usuario;

fecha;

acción;

origen;

resultado.

72. Límites de logging

No todos los sistemas externos proporcionan logs completos.

ACCIÓN DIGITAL no puede registrar información que un tercero no exponga razonablemente.

73. Datos sensibles en logs

Se procurará evitar almacenar innecesariamente en logs:

passwords;

tokens;

secretos;

contenidos sensibles completos.

74. Retención de logs

Los logs no se conservarán indefinidamente salvo necesidad contractual o legal.

La retención podrá depender de:

riesgo;

capacidad;

finalidad;

privacidad;

plan.

75. Monitorización

Cuando esté contratada, la monitorización podrá detectar eventos técnicos o de seguridad.

76. Monitorización no total

La monitorización no garantiza detectar todo ataque, vulnerabilidad o comportamiento malicioso.

77. Alertas

Las alertas podrán estar sujetas a:

umbrales;

reglas;

disponibilidad del proveedor;

canal de comunicación.

78. Repositorios

Cuando ACCIÓN DIGITAL gestione código, podrá utilizar controles sobre:

acceso;

ramas;

secretos;

commits;

despliegues.

79. Repositorios públicos

No deberá publicarse código confidencial o secretos en repositorios públicos sin autorización.

80. Dependencias

El software puede incorporar dependencias de terceros.

ACCIÓN DIGITAL podrá actualizar aquellas bajo su gestión cuando exista una razón de:

seguridad;

compatibilidad;

mantenimiento.

81. Dependencias abandonadas

Cuando una dependencia quede abandonada podrá ser necesario:

sustituirla;

eliminarla;

rediseñar el componente.

Este trabajo podrá constituir cambio de alcance cuando sea material.

82. Desarrollo

Cuando ACCIÓN DIGITAL desarrolle software procurará aplicar prácticas razonables de seguridad adecuadas al proyecto.

83. Revisión de código

Una revisión exhaustiva de seguridad de todo código no se considera incluida por defecto.

84. Código generado con IA

El código generado o asistido por inteligencia artificial deberá tratarse como código susceptible de contener:

errores;

vulnerabilidades;

dependencias problemáticas.

No deberá presumirse seguro únicamente por haber sido generado automáticamente.

85. Producción

El acceso a producción deberá limitarse a personas y sistemas que lo necesiten.

86. DEV / TEST / PROD

Cuando la arquitectura lo requiera, podrán separarse entornos.

No todos los proyectos incluyen tres entornos independientes.

87. Cambios en producción

Las modificaciones relevantes podrán requerir:

ticket;

aprobación;

backup;

prueba;

plan de rollback;

validación.

88. Emergencias

Durante una emergencia de seguridad ACCIÓN DIGITAL podrá adoptar medidas extraordinarias dentro de sus facultades contractuales.

89. Acciones de emergencia

Podrán incluir:

bloquear acceso;

suspender un agente;

detener automatización;

aislar servidor;

cerrar puerto;

revocar token;

forzar logout;

cambiar credencial;

bloquear IP;

desconectar integración.

90. Prioridad de seguridad

Cuando exista un riesgo grave, la protección de:

personas;

datos;

integridad;

infraestructura;

podrá prevalecer temporalmente sobre la continuidad de una funcionalidad no esencial.

91. Suspensión preventiva

ACCIÓN DIGITAL podrá suspender temporalmente un componente cuando exista una sospecha razonable de que mantenerlo operativo puede agravar un incidente grave.

92. Proporcionalidad

La medida deberá limitarse, cuando resulte técnicamente razonable, al componente necesario para contener el riesgo.

93. Incidente de seguridad

Podrá considerarse incidente, entre otros:

acceso no autorizado;

malware;

pérdida de credencial;

filtración;

modificación no autorizada;

eliminación;

ejecución maliciosa;

vulnerabilidad explotada.

94. Comunicación de incidentes por el CLIENTE

El CLIENTE deberá informar sin demora indebida cuando detecte:

pérdida de dispositivo;

robo de credencial;

usuario comprometido;

email sospechoso;

acceso anómalo;

fuga potencial;

malware;

actividad no autorizada.

95. Canal de incidentes

Mientras no exista un canal específico distinto, podrá utilizarse:

info@acciondigital.es

para comunicar una incidencia de seguridad.

96. Respuesta a incidentes

ACCIÓN DIGITAL podrá aplicar un proceso como:

DETECTAR → CONTENER → PRESERVAR EVIDENCIA → ANALIZAR → CORREGIR → RECUPERAR → VERIFICAR → DOCUMENTAR

97. Prioridad durante incidentes

Durante un incidente podrá priorizarse:

1. seguridad;

2. contención;

3. integridad;

4. recuperación;

5. análisis definitivo.

98. Evidencias

ACCIÓN DIGITAL podrá preservar información razonablemente necesaria para investigar:

logs;

eventos;

snapshots;

tickets;

registros;

configuraciones.

99. No manipulación de evidencias

Durante un incidente grave, el CLIENTE deberá evitar acciones no coordinadas que destruyan información necesaria para el diagnóstico.

100. Brechas de datos personales

Cuando un incidente afecte datos personales se aplicará adicionalmente:

RGPD;

Política de Privacidad;

DPA.

101. ACCIÓN DIGITAL como encargado

Cuando ACCIÓN DIGITAL actúe como encargado del tratamiento, informará al responsable de las violaciones de seguridad de datos personales de las que tenga conocimiento conforme al DPA aplicable.

102. Evaluación del responsable

Corresponderá al CLIENTE, cuando actúe como responsable, adoptar las decisiones y realizar las notificaciones que legalmente le correspondan, sin perjuicio de la asistencia contratada de ACCIÓN DIGITAL.

103. Cooperación

ACCIÓN DIGITAL proporcionará la información razonablemente disponible que resulte necesaria para que el CLIENTE pueda gestionar el incidente conforme al papel de cada Parte.

104. Informe de incidente

Cuando sea proporcionado al riesgo o esté contratado, podrá elaborarse un informe con:

cronología;

alcance;

impacto;

causa conocida;

medidas;

recomendaciones.

105. Causa no determinada

No siempre será posible determinar con certeza absoluta la causa raíz.

Cuando ocurra, se distinguirá entre:

hecho verificado;

evidencia;

hipótesis;

conclusión.

106. Proveedores

La seguridad de un Servicio podrá depender parcialmente de terceros.

Por ejemplo:

hosting;

cloud;

SaaS;

proveedor de IA;

correo;

DNS;

registrador;

CDN.

107. Evaluación de proveedores

ACCIÓN DIGITAL procurará seleccionar proveedores adecuados a la función correspondiente.

Cuando procesen datos personales se aplicarán además las obligaciones previstas en el DPA.

108. Seguridad upstream

ACCIÓN DIGITAL no controla directamente todos los mecanismos internos de seguridad de un proveedor upstream.

109. Incidente upstream

Cuando un incidente tenga origen en un tercero, ACCIÓN DIGITAL podrá:

investigar;

escalar;

aplicar mitigaciones;

cambiar configuración;

evaluar migración.

110. Subencargados

Cuando corresponda se aplicará:

13 — Subencargados.

111. Cambios de proveedor

Un cambio de proveedor podrá requerirse por:

riesgo;

vulnerabilidad;

fin de soporte;

cumplimiento;

disponibilidad.

112. Seguridad de IA

Los sistemas de inteligencia artificial estarán sujetos adicionalmente a:

06 — Condiciones de Inteligencia Artificial.

113. Prompt injection

Los sistemas de IA que consuman información externa pueden estar expuestos a instrucciones maliciosas.

ACCIÓN DIGITAL podrá aplicar controles, pero no garantiza la eliminación absoluta de dicho riesgo.

114. Acciones de agentes

Un agente solo deberá disponer de las herramientas y permisos adecuados a su nivel de autonomía autorizado.

115. Human approval

Cuando una acción requiera aprobación humana, el CLIENTE no deberá eliminar dicho control sin evaluación previa cuando forme parte de la arquitectura de seguridad.

116. Kill switch de agentes

Los agentes con capacidad de ejecución podrán disponer de mecanismos de suspensión cuando estén incluidos en la arquitectura.

117. Protección de API de IA

Podrán utilizarse:

claves separadas;

límites;

cuentas independientes;

presupuestos;

control de herramientas.

118. Responsabilidad del CLIENTE sobre contenidos

El CLIENTE deberá evitar utilizar los sistemas para:

malware;

fraude;

ataques;

phishing;

actividad ilícita.

Será aplicable:

11 — Acceptable Use Policy.

119. Incumplimiento de seguridad por el CLIENTE

Cuando el CLIENTE incumpla una medida obligatoria que afecte directamente a la seguridad, ACCIÓN DIGITAL podrá:

advertir;

limitar acceso;

suspender componente;

exigir corrección.

120. Riesgo grave no corregido

Si una configuración bajo control del CLIENTE representa un riesgo grave para:

otros clientes;

infraestructura;

terceros;

datos;

ACCIÓN DIGITAL podrá suspender el componente afectado.

121. Impacto sobre SLA

Un incidente directamente causado por incumplimiento de las obligaciones de seguridad del CLIENTE podrá quedar excluido del SLA en los términos del documento 08 — SLA y Soporte.

122. Excepciones documentadas

El CLIENTE podrá solicitar una excepción a una medida recomendada.

ACCIÓN DIGITAL podrá:

aceptarla;

exigir controles compensatorios;

rechazarla;

según el riesgo.

123. Aceptación de riesgo

Cuando una excepción sea aceptada podrá documentarse:

RIESGO MEDIDA RECOMENDADA DECISIÓN DEL CLIENTE CONTROL COMPENSATORIO FECHA RESPONSABLE

124. Riesgo no transferible

La aceptación de un riesgo por el CLIENTE no elimina obligaciones legales imperativas de ACCIÓN DIGITAL.

125. Auditorías

Cuando exista una obligación contractual o legal de auditoría, ACCIÓN DIGITAL colaborará razonablemente.

126. Acceso a evidencias

El CLIENTE no adquiere automáticamente derecho ilimitado a acceder a:

sistemas internos;

credenciales;

datos de otros clientes;

configuraciones defensivas sensibles;

código de herramientas internas.

127. Evidencia alternativa

Cuando no pueda facilitarse acceso directo, podrán utilizarse, según corresponda:

documentación;

capturas;

informes;

registros;

certificados;

evidencia técnica;

auditoría controlada.

128. Auditorías del CLIENTE

Una auditoría solicitada por el CLIENTE deberá:

coordinarse;

respetar confidencialidad;

no comprometer terceros;

no afectar producción;

limitarse al alcance relevante.

Los costes extraordinarios podrán ser facturables cuando legal y contractualmente proceda.

129. Certificaciones

La existencia de controles de seguridad no implica que ACCIÓN DIGITAL posea:

ISO 27001;

ENS;

SOC 2;

otra certificación;

salvo que se indique expresamente y sea verificable.

130. Requisitos regulatorios del CLIENTE

Si el CLIENTE está sometido a obligaciones sectoriales específicas deberá comunicarlas antes de contratar.

131. NIS2 y otras normas sectoriales

Cuando un CLIENTE o Servicio esté sujeto a un régimen específico de ciberseguridad, las Partes deberán determinar las obligaciones adicionales aplicables.

La contratación ordinaria de un Servicio tecnológico no implica automáticamente cumplimiento completo de cualquier normativa sectorial del CLIENTE.

132. Continuidad de negocio

La seguridad no equivale a continuidad.

La continuidad puede requerir:

redundancia;

backup;

recuperación;

failover;

procedimientos;

personal.

Estos elementos deberán contratarse cuando sean necesarios.

133. Disaster Recovery

Un plan formal de Disaster Recovery no está incluido por defecto.

134. RTO y RPO

Solo existirán compromisos específicos de RTO/RPO cuando hayan sido definidos contractualmente.

135. Pruebas de recuperación

Las pruebas de restauración o recuperación solo se realizarán con la periodicidad contratada.

136. Cambios del CLIENTE

Cuando el CLIENTE modifique:

firewall;

permisos;

software;

DNS;

workflows;

usuarios;

código;

infraestructura;

deberá asumir las consecuencias de seguridad directamente atribuibles a dichos cambios cuando se hayan realizado fuera del procedimiento acordado.

137. Cambios de terceros

Cuando un tercero contratado por el CLIENTE realice modificaciones, el CLIENTE deberá procurar coordinar dichas actuaciones.

138. Derecho a diagnóstico

Ante un incidente ACCIÓN DIGITAL podrá solicitar información sobre cambios recientes para determinar la causa.

139. Configuración soportada

ACCIÓN DIGITAL podrá exigir que un sistema vuelva a una configuración soportada antes de asumir nuevamente determinados compromisos de mantenimiento o SLA.

140. Seguridad y disponibilidad

Una medida de seguridad puede requerir temporalmente:

suspensión;

reinicio;

bloqueo;

reducción de funcionalidad.

Cuando sea razonablemente necesario para evitar un daño superior, dicha actuación no constituirá automáticamente incumplimiento.

141. Seguridad frente a comodidad

ACCIÓN DIGITAL podrá rechazar configuraciones que reduzcan materialmente la seguridad únicamente por conveniencia cuando puedan poner en riesgo infraestructura compartida o terceros.

142. Documentación interna

ACCIÓN DIGITAL podrá mantener documentación interna sobre:

arquitectura;

inventario;

accesos;

riesgos;

procedimientos;

incidentes;

activos.

143. Información no pública

Por motivos de seguridad, ACCIÓN DIGITAL no está obligada a publicar detalles como:

direcciones internas;

topologías completas;

reglas exactas de firewall;

credenciales;

claves;

configuraciones de detección;

mecanismos internos sensibles.

144. Anexo de Medidas Técnicas y Organizativas

Cuando resulte necesario, podrá existir un documento privado:

Anexo de Medidas Técnicas y Organizativas — TOMs

que describa con mayor precisión controles relacionados con el tratamiento de datos personales.

145. El documento público no es un pentest

La presente Política describe el marco contractual de seguridad.

No constituye:

auditoría;

certificación;

pentest;

garantía técnica exhaustiva.

146. Formación interna

ACCIÓN DIGITAL podrá adoptar medidas razonables de sensibilización y formación de las personas con acceso a sistemas.

147. Personal autorizado

El acceso interno deberá limitarse al personal que necesite acceder para:

prestar;

mantener;

soportar;

proteger;

el Servicio.

148. Confidencialidad del personal

Las personas autorizadas estarán sujetas a las obligaciones de confidencialidad que resulten aplicables.

149. Cambios de personal

Cuando una persona de ACCIÓN DIGITAL deje de necesitar acceso, deberán revocarse los accesos que correspondan conforme a los procedimientos aplicables.

150. Acceso excepcional

Puede ser necesario conceder temporalmente acceso ampliado para:

incidente;

migración;

recuperación;

mantenimiento.

Dicho acceso deberá retirarse cuando deje de ser necesario cuando técnicamente corresponda.

151. Seguridad durante Offboarding

La terminación deberá incluir, cuando corresponda:

revocación de usuarios;

revocación de tokens;

devolución de accesos;

transferencia;

eliminación;

rotación de secretos compartidos.

152. Responsabilidad del CLIENTE tras salida

Una vez transferido el control del sistema y revocados los accesos de ACCIÓN DIGITAL, la seguridad posterior corresponderá al CLIENTE o a su nuevo proveedor, salvo obligación residual expresamente pactada.

153. Custodia de credenciales tras terminación

El CLIENTE deberá rotar aquellas credenciales que deban dejar de estar disponibles para ACCIÓN DIGITAL después de finalizar el Servicio cuando el proceso no permita revocarlas directamente.

154. Eliminación de accesos de ACCIÓN DIGITAL

ACCIÓN DIGITAL procurará eliminar o revocar los accesos que ya no sean necesarios tras finalizar el Servicio.

155. Conservación de evidencias

Determinadas evidencias de seguridad podrán mantenerse después de la terminación cuando resulte necesario por:

obligación legal;

reclamaciones;

auditoría;

defensa;

investigación.

156. Responsabilidad

El régimen de responsabilidad será el establecido en:

04 — Condiciones Generales de Servicios Tecnológicos.

157. Incumplimiento atribuible

La existencia de un incidente no determina por sí sola qué Parte es responsable.

Deberán analizarse:

causa;

control afectado;

obligaciones asumidas;

actuación de cada Parte;

medidas aplicadas;

advertencias realizadas.

158. Advertencias documentadas

Cuando ACCIÓN DIGITAL identifique un riesgo relevante podrá documentarlo mediante:

ticket;

informe;

SOW;

email;

registro de riesgos.

159. Cooperación

Ambas Partes deberán colaborar razonablemente para:

prevenir;

detectar;

contener;

investigar;

recuperar;

incidentes de seguridad.

160. Matriz general de responsabilidad

Como criterio general, salvo que el SOW indique otra cosa:

161. Matriz específica

La tabla anterior es general.

Cuando exista una contradicción, prevalecerá la matriz específica incluida en:

SOW;

DPA;

Anexo de Seguridad;

Orden correspondiente.

162. Revisión periódica

La distribución de responsabilidades podrá revisarse cuando cambie:

arquitectura;

proveedor;

criticidad;

alcance;

normativa.

163. Modificaciones

Las modificaciones de estas Condiciones se regirán por las Condiciones Generales.

164. Legislación aplicable

Será aplicable la legislación indicada en las Condiciones Generales y, cuando exista tratamiento de datos personales, la normativa correspondiente de protección de datos.

165. Contacto

Para cuestiones relativas a seguridad:

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

Hasta la habilitación de un canal específico de seguridad, esta dirección podrá utilizarse para comunicaciones relacionadas con incidentes o vulnerabilidades.

Versión: 1.0

Fecha: 7 de agosto de 2026