SEGURIDAD Y DIVULGACIÓN RESPONSABLE DE VULNERABILIDADES
Última actualización: 7 de agosto de 2026
Versión: 1.0
1. Objeto
ACCION DIGITAL LOCAL S.L. considera la seguridad de sus sistemas, infraestructura y servicios un elemento esencial de su actividad.
La presente Política establece:
cómo comunicar una posible vulnerabilidad;
qué información debe incluir un reporte;
cómo gestionará ACCIÓN DIGITAL las comunicaciones recibidas;
qué actividades están permitidas;
qué actividades no están autorizadas;
cómo se coordinará, cuando proceda, la divulgación de una vulnerabilidad.
Esta Política no constituye un programa público de bug bounty ni una autorización general para realizar pruebas de penetración.
2. Responsable
ACCION DIGITAL LOCAL S.L.
NIF: B75510008
Domicilio: Avinguda de les Glòries Catalanes, 62, Bloc B, Can Palet, 08223 Terrassa, Barcelona, España
Sitio web: acciondigital.es
Contacto actual de seguridad: info@acciondigital.es
En adelante, “ACCIÓN DIGITAL”.
3. Finalidad de esta Política
El objetivo es facilitar que investigadores, clientes, proveedores, usuarios y terceros puedan comunicar de buena fe vulnerabilidades o problemas de seguridad detectados sin:
causar daños;
acceder innecesariamente a datos;
interrumpir servicios;
afectar a terceros;
divulgar prematuramente información sensible.
4. Divulgación coordinada
ACCIÓN DIGITAL favorece un modelo de Coordinated Vulnerability Disclosure — CVD.
Esto significa que, cuando una vulnerabilidad sea comunicada de buena fe, se procurará:
1. recibir el reporte;
2. verificarlo;
3. clasificar su riesgo;
4. contenerlo cuando sea necesario;
5. desarrollar o coordinar una mitigación;
6. validar la corrección;
7. coordinar cualquier eventual divulgación pública.
5. Esta Política no autoriza pentesting general
La publicación de esta Política:
NO autoriza por sí sola
a realizar:
pentesting;
explotación activa;
escaneos agresivos;
ataques;
bypass de controles;
acceso a sistemas restringidos;
ingeniería social;
pruebas de denegación de servicio;
extracción de datos.
Las pruebas activas requerirán autorización expresa cuando corresponda.
6. Activos bajo control de terceros
ACCIÓN DIGITAL no puede autorizar pruebas contra infraestructura perteneciente o controlada por terceros.
Esto puede incluir:
proveedores cloud;
datacenters;
APIs;
SaaS;
servicios de correo;
CDN;
DNS;
proveedores de inteligencia artificial;
plataformas externas.
Las políticas de seguridad y divulgación del proveedor correspondiente deberán respetarse.
7. Activos de clientes
Esta Política tampoco concede autorización para realizar pruebas sobre:
sitios web de clientes;
VPS de clientes;
bases de datos de clientes;
sistemas de clientes;
cuentas de clientes;
aunque ACCIÓN DIGITAL participe en su administración.
Cualquier prueba sobre dichos activos requerirá la autorización suficiente del titular correspondiente.
8. Descubrimiento accidental
Si una persona descubre accidentalmente una posible vulnerabilidad durante el uso normal de un Servicio, deberá:
1. detener cualquier actuación que pudiera ampliar el acceso;
2. evitar consultar información innecesaria;
3. no modificar datos;
4. no eliminar información;
5. preservar únicamente la evidencia mínima necesaria;
6. comunicar el hallazgo a ACCIÓN DIGITAL.
9. Principio de mínima intervención
Una persona que reporte una vulnerabilidad deberá limitar sus actuaciones a aquello estrictamente necesario para demostrar razonablemente su existencia.
No deberá intentar determinar:
“hasta dónde puedo llegar”
cuando ello implique acceder a información o sistemas adicionales.
10. Datos personales
Si durante el descubrimiento se accede accidentalmente a datos personales:
deberá detenerse la exploración;
no deberán descargarse más datos;
no deberán compartirse;
no deberán conservarse innecesariamente;
deberá informarse a ACCIÓN DIGITAL.
11. Información confidencial
Se aplicará el mismo criterio cuando se acceda accidentalmente a:
secretos;
credenciales;
código privado;
documentación interna;
información comercial;
datos de clientes;
claves;
tokens;
configuraciones.
12. Credenciales descubiertas
Si se detectan accidentalmente:
contraseñas;
API keys;
tokens;
private keys;
secretos;
no deberán utilizarse para ampliar el acceso.
El reporte deberá indicar dónde se encontraron sin reproducir innecesariamente el secreto completo.
13. Pruebas expresamente prohibidas sin autorización
No están autorizadas mediante esta Política las siguientes actividades:
denegación de servicio;
DDoS;
flooding;
stress testing;
brute force;
credential stuffing;
password spraying;
phishing;
smishing;
vishing;
ingeniería social;
acceso físico;
malware;
ransomware;
persistencia;
exfiltración;
destrucción de datos;
modificación de datos;
creación de cuentas administrativas;
escalada deliberada de privilegios más allá de lo estrictamente necesario para verificar un hallazgo autorizado;
eliminación de recursos;
modificación de DNS;
envío masivo;
ataques contra usuarios.
14. Ingeniería social
No está permitido intentar obtener acceso mediante:
engaño a empleados;
llamadas;
emails fraudulentos;
suplantación;
solicitudes falsas de recuperación;
manipulación de soporte.
15. Pruebas físicas
Esta Política no autoriza:
acceso físico;
tailgating;
manipulación de oficinas;
dispositivos;
servidores;
instalaciones;
personal.
16. Denegación de servicio
No deberán realizarse pruebas destinadas a medir cuánto tráfico, conexiones o consumo puede soportar un Servicio hasta producir degradación.
17. Destrucción
No deberán:
eliminarse archivos;
borrar cuentas;
eliminar bases de datos;
eliminar backups;
destruir recursos;
provocar corrupción.
18. Persistencia
No deberán instalarse mecanismos destinados a mantener acceso posterior.
Por ejemplo:
usuarios;
SSH keys;
shells;
backdoors;
tokens;
scheduled tasks;
malware.
19. Movimiento lateral
No está autorizado utilizar una vulnerabilidad encontrada en un sistema para intentar acceder a:
otros servidores;
otras cuentas;
otros clientes;
otros entornos;
otros proveedores.
20. Datos de otros clientes
El acceso a datos pertenecientes a otro cliente deberá considerarse un evento especialmente sensible.
Si ocurre accidentalmente:
DETENER → NO COPIAR → NO EXPLORAR → REPORTAR
21. Prueba de impacto
Cuando resulte posible demostrar una vulnerabilidad utilizando:
una cuenta propia;
datos propios;
un objeto creado por el investigador;
deberá utilizarse ese método en lugar de acceder a datos reales de terceros.
22. Evidencia mínima
El reporte deberá contener solo la evidencia necesaria.
No deberá incluirse una descarga masiva de información para demostrar que existe una vulnerabilidad.
23. Automatización
No deberán ejecutarse scanners o herramientas automatizadas de alta intensidad contra sistemas de ACCIÓN DIGITAL sin autorización previa.
24. Escaneos de baja intensidad
El uso de herramientas automatizadas incluso de baja intensidad puede estar sujeto a:
rate limits;
sistemas antiabuso;
bloqueos automáticos.
La ausencia de bloqueo no constituye autorización.
25. Activos expresamente autorizados
En el futuro, ACCIÓN DIGITAL podrá publicar un listado específico:
IN SCOPE
para determinadas pruebas.
Hasta que dicho listado exista, esta Política debe considerarse principalmente un canal de reporte y divulgación coordinada, no una autorización abierta de hacking ético.
26. Activos fuera de alcance
Se considerarán fuera de alcance, salvo autorización específica:
terceros;
clientes;
sistemas compartidos;
proveedores upstream;
servicios no identificados expresamente;
entornos ajenos a ACCIÓN DIGITAL.
27. Autorizaciones específicas
ACCIÓN DIGITAL podrá conceder autorización individual para realizar pruebas.
La autorización podrá definir:
ACTIVO FECHA IP / DOMINIO TIPO DE TEST HORARIO LÍMITES TÉCNICAS PROHIBIDAS RESPONSABLE CONDICIÓN DE PARADA
28. Condición de parada
Toda prueba autorizada deberá detenerse cuando se produzca cualquiera de las siguientes circunstancias:
acceso a datos personales no previstos;
acceso a secretos;
impacto sobre terceros;
degradación;
pérdida de disponibilidad;
comportamiento no previsto;
riesgo de daño.
29. Cómo reportar
Las vulnerabilidades podrán comunicarse inicialmente mediante:
info@acciondigital.es
indicando claramente en el asunto:
[SECURITY] Vulnerability Report
Cuando se habilite un canal específico, ACCIÓN DIGITAL podrá sustituir este mecanismo por:
security@acciondigital.es
30. Información recomendada
Un reporte debería incluir:
nombre o alias del investigador;
información de contacto;
activo afectado;
URL o endpoint;
fecha de detección;
descripción;
impacto potencial;
pasos para reproducir;
prerequisitos;
evidencia mínima;
versión afectada cuando se conozca;
recomendación de corrección cuando exista.
31. Plantilla
Puede utilizarse la siguiente estructura:
ASUNTO: [SECURITY] Vulnerability Report ACTIVO AFECTADO: [...] VULNERABILIDAD: [...] IMPACTO: [...] PASOS PARA REPRODUCIR: 1. 2. 3. RESULTADO ESPERADO: [...] RESULTADO OBSERVADO: [...] EVIDENCIA: [...] FECHA: [...] CONTACTO: [...]
32. Capturas
Podrán incluirse capturas cuando resulten necesarias.
Antes de enviarlas deberán ocultarse, cuando sea posible:
datos personales innecesarios;
contraseñas;
tokens;
secretos;
información de terceros.
33. Vídeos
Un vídeo podrá utilizarse para demostrar un comportamiento complejo siempre que no muestre innecesariamente información de terceros.
34. Proof of Concept
Un Proof of Concept deberá limitarse al código mínimo necesario para reproducir el problema.
No deberá diseñarse para:
automatizar explotación masiva;
persistir;
exfiltrar;
causar daño.
35. Código malicioso
No deberán enviarse ejecutables maliciosos sin coordinación previa.
36. Adjuntos
Los adjuntos sospechosos podrán ser bloqueados automáticamente por los sistemas de seguridad.
Cuando sea necesario enviar una muestra, deberá coordinarse previamente el mecanismo adecuado.
37. Cifrado de comunicaciones
Para vulnerabilidades especialmente sensibles, ACCIÓN DIGITAL podrá habilitar un mecanismo adicional de intercambio seguro.
38. PGP
La publicación de esta Política no implica actualmente que exista una clave PGP oficial.
Si se habilita en el futuro, su fingerprint deberá publicarse en un canal oficial de ACCIÓN DIGITAL.
39. Confirmación de recepción
ACCIÓN DIGITAL procurará confirmar la recepción de reportes de seguridad legítimos dentro de un plazo razonable.
La confirmación no significa que la vulnerabilidad haya sido validada.
40. Clasificación
Los reportes podrán clasificarse atendiendo a:
impacto;
explotabilidad;
alcance;
exposición;
datos afectados;
privilegios necesarios;
interacción requerida.
41. Sistemas de puntuación
ACCIÓN DIGITAL podrá utilizar sistemas como:
CVSS;
evaluación interna;
criterios de impacto empresarial;
como apoyo para priorizar una vulnerabilidad.
42. Severidad no automática
Una puntuación CVSS no determinará por sí sola la prioridad final.
También podrán considerarse:
contexto;
controles existentes;
exposición real;
datos;
clientes afectados.
43. Proceso interno
El flujo podrá ser:
RECEPCIÓN → TRIAGE → REPRODUCCIÓN → CLASIFICACIÓN → CONTENCIÓN → CORRECCIÓN → QA → DESPLIEGUE → VERIFICACIÓN → CIERRE
44. Reproducción
ACCIÓN DIGITAL intentará reproducir el problema dentro de un entorno controlado cuando resulte posible.
45. Vulnerabilidad confirmada
Cuando el problema quede confirmado se podrá:
abrir incidencia interna;
priorizar;
aplicar mitigación;
desarrollar corrección;
contactar con proveedores afectados.
46. Vulnerabilidad de tercero
Cuando la vulnerabilidad se encuentre realmente en un:
proveedor;
software;
librería;
API;
producto de tercero;
ACCIÓN DIGITAL podrá:
comunicarla al proveedor;
aplicar mitigaciones;
actualizar;
desactivar temporalmente el componente.
47. Coordinación con INCIBE-CERT
Cuando resulte adecuado, ACCIÓN DIGITAL podrá solicitar apoyo de INCIBE-CERT para coordinar la divulgación de una vulnerabilidad que afecte a:
productos;
proveedores;
terceros;
múltiples organizaciones.
48. CVE
Cuando una vulnerabilidad reúna los requisitos correspondientes, podrá coordinarse la solicitud o asignación de un identificador CVE mediante los mecanismos reconocidos.
ACCIÓN DIGITAL no garantiza que cualquier reporte reciba un CVE.
49. Vulnerabilidad no reproducible
Un reporte podrá cerrarse como no reproducible cuando, después de un análisis razonable, no pueda confirmarse.
El investigador podrá aportar información adicional.
50. Informational
Determinadas observaciones podrán clasificarse como:
INFORMATIONAL
cuando no representen una vulnerabilidad explotable relevante.
51. Duplicate
Cuando una vulnerabilidad ya haya sido reportada previamente podrá clasificarse como:
DUPLICATE.
52. Known Issue
También podrá tratarse como:
KNOWN ISSUE
cuando ya exista una corrección o mitigación planificada.
53. Not Applicable
Podrá clasificarse como:
NOT APPLICABLE
cuando el comportamiento:
sea intencionado;
esté fuera de alcance;
no produzca un impacto razonable;
pertenezca a un tercero.
54. Buenas prácticas frente a investigador
ACCIÓN DIGITAL procurará mantener una comunicación profesional y de buena fe con las personas que realicen reportes legítimos.
55. Ausencia de recompensa económica
Esta Política no constituye un Bug Bounty Program.
Por tanto, el envío de una vulnerabilidad no genera automáticamente derecho a:
recompensa;
pago;
comisión;
contratación;
contraprestación económica.
56. Recompensas discrecionales
ACCIÓN DIGITAL podrá reconocer voluntariamente una contribución cuando lo considere adecuado.
Cualquier recompensa requerirá acuerdo expreso.
57. Ausencia de obligación de reconocimiento público
El envío de un reporte tampoco genera automáticamente derecho a reconocimiento público.
58. Crédito al investigador
Cuando ambas partes estén de acuerdo y la divulgación resulte adecuada, ACCIÓN DIGITAL podrá reconocer al investigador mediante:
nombre;
alias;
organización.
59. Anonimato
Un investigador podrá solicitar no ser identificado públicamente.
60. Divulgación pública
El investigador deberá evitar divulgar públicamente detalles técnicos que permitan explotar una vulnerabilidad antes de que:
exista corrección;
exista mitigación suficiente;
se haya coordinado razonablemente la divulgación.
61. No existe plazo universal fijo
El tiempo necesario para corregir una vulnerabilidad dependerá de:
gravedad;
complejidad;
dependencias;
proveedores;
despliegue;
riesgo de regresión.
Esta Política no establece un plazo universal obligatorio de divulgación.
62. Coordinación de publicación
Cuando exista interés legítimo en publicar el hallazgo, las partes procurarán acordar:
fecha;
nivel de detalle;
atribución;
CVE cuando proceda;
recomendaciones.
63. Explotación activa conocida
Cuando exista evidencia de explotación activa, ACCIÓN DIGITAL podrá priorizar:
mitigación;
despliegue urgente;
comunicación anticipada;
sobre el calendario ordinario de divulgación.
64. Riesgo para clientes
Si una vulnerabilidad confirmada representa un riesgo material para clientes, ACCIÓN DIGITAL evaluará las comunicaciones necesarias conforme a:
impacto;
contrato;
seguridad;
protección de datos;
normativa aplicable.
65. Información que puede mantenerse reservada
Podrán mantenerse temporalmente confidenciales detalles como:
exploit completo;
credenciales;
arquitectura sensible;
activos afectados;
mecanismos de bypass;
información de terceros.
66. Protección frente a weaponization
La publicación de información técnica deberá evitar, cuando resulte razonable, facilitar innecesariamente la explotación de sistemas todavía vulnerables.
67. Datos personales del investigador
Los datos de contacto proporcionados por el investigador serán utilizados para:
gestionar el reporte;
comunicarse;
investigar;
documentar;
defender derechos cuando sea necesario.
68. Conservación
Los reportes podrán conservarse durante el tiempo necesario para:
gestionar la vulnerabilidad;
mantener trazabilidad;
prevenir regresiones;
gestionar responsabilidades;
cumplir obligaciones legales.
69. Confidencialidad del reporte
ACCIÓN DIGITAL procurará limitar internamente el acceso al reporte a personas que necesiten conocerlo para:
análisis;
corrección;
seguridad;
gestión jurídica.
70. Compartición con proveedores
Podrá ser necesario compartir información limitada con:
proveedor upstream;
desarrollador;
fabricante;
proveedor cloud;
INCIBE-CERT;
asesor especializado;
cuando resulte necesario para resolver o coordinar la vulnerabilidad.
71. Minimización al compartir
Cuando sea posible, se eliminará información no necesaria antes de compartir un reporte con terceros.
72. Obligaciones legales
ACCIÓN DIGITAL podrá comunicar información a autoridades cuando exista:
obligación legal;
requerimiento válido;
riesgo grave que jurídicamente lo justifique.
73. Vulnerabilidad con posible brecha de datos
Si el hallazgo puede haber provocado acceso real no autorizado a datos personales, se activará además el procedimiento de incidente correspondiente.
74. Vulnerabilidad ≠ brecha automáticamente
La existencia de una vulnerabilidad técnica no significa necesariamente que se haya producido una violación de seguridad de datos personales.
Deberá evaluarse si existió:
acceso;
pérdida;
alteración;
divulgación;
destrucción.
75. Preservación de evidencia
ACCIÓN DIGITAL podrá conservar:
logs;
snapshots;
registros;
tickets;
información técnica;
cuando resulte necesario para investigar el hallazgo.
76. No alteración posterior
Cuando ACCIÓN DIGITAL solicite detener pruebas para preservar evidencias o evitar riesgo, deberán cesar las actuaciones correspondientes.
77. Buena fe
Se considerará especialmente relevante que la persona que reporta:
actúe con finalidad defensiva;
minimice el impacto;
no busque beneficio mediante amenaza;
respete confidencialidad;
coopere en la corrección.
78. Extorsión
No se considerará divulgación responsable condicionar la no publicación o no explotación de una vulnerabilidad al pago de una cantidad no previamente acordada.
79. Amenazas
Las amenazas de:
publicar;
atacar;
vender datos;
explotar;
interrumpir servicios;
podrán ser tratadas como un incidente independiente y comunicadas a las autoridades cuando proceda.
80. Datos obtenidos mediante exceso de acceso
La buena intención declarada no convierte automáticamente en autorizada una extracción excesiva de información.
81. Safe Harbor
Esta Política no constituye un safe harbor jurídico general ni una renuncia de ACCIÓN DIGITAL a ejercer derechos frente a actuaciones ilícitas o realizadas fuera de autorización.
82. Investigación autorizada separadamente
Cuando exista una autorización expresa de seguridad emitida por ACCIÓN DIGITAL, ésta definirá los límites concretos de las pruebas autorizadas.
83. Actuaciones dentro de autorización
ACCIÓN DIGITAL valorará de forma diferenciada aquellas actuaciones realizadas:
de buena fe;
dentro del alcance;
respetando límites;
minimizando daños;
de aquellas que excedan la autorización concedida.
84. Actuaciones fuera de autorización
ACCIÓN DIGITAL se reserva sus derechos respecto de actividades como:
acceso deliberadamente no autorizado;
exfiltración;
destrucción;
extorsión;
persistencia;
publicación perjudicial prematura;
afectación a terceros;
fraude.
85. Errores propios no constituyen permiso
Que un sistema permita técnicamente realizar una acción no significa que exista autorización contractual o legal para realizarla.
86. Controles débiles no equivalen a consentimiento
La ausencia o debilidad de una medida de seguridad tampoco deberá interpretarse como autorización para acceder a recursos ajenos.
87. Seguridad de clientes
Los reportes relacionados exclusivamente con sistemas de un cliente podrán requerir coordinación con dicho cliente.
ACCIÓN DIGITAL no revelará innecesariamente la identidad o datos de clientes afectados.
88. Multi-tenant
Cuando una vulnerabilidad pueda afectar a varios clientes o entornos, el investigador no deberá intentar comprobar manualmente cada tenant.
Una demostración mínima será suficiente para el reporte.
89. Supply chain
Si el problema afecta a una dependencia utilizada en varios sistemas, ACCIÓN DIGITAL podrá gestionar el hallazgo como una vulnerabilidad de cadena de suministro.
90. Actualizaciones de seguridad
Una corrección puede consistir en:
patch;
actualización;
cambio de configuración;
mitigación;
desactivación;
sustitución de componente.
91. Corrección definitiva
Una mitigación temporal no deberá interpretarse necesariamente como corrección definitiva.
92. Regression testing
Cuando resulte proporcionado, una corrección podrá ser sometida a pruebas para evitar:
regresiones;
incompatibilidades;
nuevos fallos.
93. Verificación por investigador
ACCIÓN DIGITAL podrá solicitar al investigador que confirme si la corrección resuelve el hallazgo.
Dicha colaboración será voluntaria salvo acuerdo previo.
94. Retest
Un retest deberá limitarse al hallazgo previamente comunicado y a las actuaciones autorizadas.
95. Cambios tecnológicos
Los activos y proveedores utilizados por ACCIÓN DIGITAL evolucionan.
Esta Política podrá modificarse para reflejar:
nuevos sistemas;
nuevos canales;
nuevos requisitos;
cambios regulatorios.
96. security.txt
ACCIÓN DIGITAL podrá publicar posteriormente un archivo estándar:
/.well-known/security.txt
para facilitar:
contacto;
política;
idiomas;
caducidad;
canal de reporte.
97. Automatización del reporte
Podrán implantarse en el futuro:
formularios;
ticketing;
cifrado;
plataformas especializadas.
98. Programa Bug Bounty futuro
Si ACCIÓN DIGITAL crea un programa de recompensas, éste dispondrá de condiciones independientes que especificarán:
scope;
recompensas;
severidades;
activos;
exclusiones;
reglas.
99. Relación con la AUP
El uso abusivo o no autorizado de los sistemas estará sujeto también a:
11 — Acceptable Use Policy.
100. Relación con Seguridad y Responsabilidad Compartida
Los controles internos y responsabilidades de seguridad se regulan adicionalmente mediante:
09 — Seguridad y Responsabilidad Compartida.
101. Relación con SLA
Los tiempos de gestión de incidentes contratados se regularán mediante:
08 — SLA y Soporte.
La presente Política no crea por sí sola un SLA público para investigadores.
102. Relación con DPA
Cuando una vulnerabilidad afecte a datos tratados por cuenta de un CLIENTE será aplicable adicionalmente:
15 — DPA.
103. No certificación
Esta Política no constituye:
certificación de seguridad;
garantía de ausencia de vulnerabilidades;
auditoría;
pentest;
declaración de cumplimiento absoluto.
104. Modificaciones
ACCIÓN DIGITAL podrá actualizar esta Política para adaptarla a:
nuevos riesgos;
amenazas;
sistemas;
buenas prácticas;
normativa.
La versión vigente será la publicada en el sitio web.
105. Legislación aplicable
Las actuaciones relacionadas con esta Política estarán sujetas a la legislación española y europea aplicable.
La presente Política no pretende autorizar ninguna conducta que legalmente requiera autorización adicional.
106. Separabilidad
Si alguna disposición resultara inválida o inaplicable, el resto de la Política continuará siendo aplicable cuando pueda subsistir jurídicamente.
107. Contacto de seguridad
Para comunicar actualmente una posible vulnerabilidad:
ACCION DIGITAL LOCAL S.L.
Email: info@acciondigital.es
Asunto recomendado: [SECURITY] Vulnerability Report
Se recomienda no enviar datos personales, secretos o información sensible que no resulte necesaria para describir el problema.
Cuando se habilite el canal dedicado, esta Política podrá actualizarse para utilizar:
security@acciondigital.es
Versión: 1.0
Fecha: 7 de agosto de 2026