¿Tu agencia recibe avisos de seguridad y cada uno acaba gestionándose de forma distinta? Sin una política clara, el correo se llena de dudas, se repiten respuestas y se pierden minutos valiosos cuando más importa coordinar bien al equipo, al cliente y, si aplica, al proveedor.
Qué resuelve esta política en tu agencia WordPress
Una política bien escrita ordena la entrada de reportes y reduce fricción con investigadores, clientes y proveedores. Sirve para responder con criterio, no con improvisación.
Divulgación responsable y coordinada
La responsible disclosure permite que un investigador avise antes de publicar un fallo. La coordinated vulnerability disclosure va un paso más allá, porque la agencia coordina la corrección y la publicación con tiempos pactados.
Lo que omiten la mayoría de guías sobre este punto es que la diferencia no está en el nombre. Está en el proceso. Si nadie confirma recepción, la coordinación se rompe el primer día.
Riesgo operativo si no hay política
Sin política, el primer bloqueo suele ser interno. Seguridad recibe el aviso. Soporte cree que lo gestiona otro. Legal no sabe si debe entrar. El resultado es lento y previsible.
Un caso habitual: una agencia recibe un aviso sobre un plugin vulnerable en un multisite, pero no tiene dueño asignado. El reporte tarda días en moverse. La corrección llega tarde y el cliente pierde confianza.
Una política útil evita que el reporte dependa de la persona que abre el correo.
Encaje en mantenimiento WordPress
En mantenimiento WordPress, la política no solo cubre el formulario de contacto. También ordena lo que pasa con plugins, temas, hosting, CDN y servicios externos.
Esto funciona bien en teoría, pero en la práctica falla cuando el alcance no distingue entre activos propios y dependencias de terceros. Ahí se mezclan responsabilidades y el triage se vuelve ambiguo.
Define el alcance con precisión y evita huecos
El alcance decide qué entra en la política y qué queda fuera. Si esa parte queda vaga, el primer reporte serio abre una discusión innecesaria.
Dominios, subdominios y aplicaciones
La política debe listar dominios, subdominios, entornos de prueba y aplicaciones web cubiertas. Si la agencia usa varias marcas o varios clientes con infraestructuras separadas, conviene separarlas por bloques.
La frase que mejor funciona aquí es directa: solo cubrimos los activos que aparecen en esta política. Todo lo demás queda fuera salvo autorización expresa.
Los datos apuntan a que la ambigüedad en el scope multiplica los correos de ida y vuelta. En 2026, muchas guías del NIST y del CISA insisten en documentar el alcance antes de recibir reportes.
Plugins, temas y hosting
En WordPress, el alcance debe decir si cubre core, plugins, temas, mu-plugins y configuraciones del servidor. También debe aclarar qué parte asume la agencia y cuál depende del proveedor de hosting.
La mayoría de guías dicen “incluya todo lo relevante”. Lo que no mencionan es que eso produce conflictos cuando el fallo vive en un servicio tercero, como un CDN o un plugin SaaS.
Un redactado útil separa tres capas: código propio, componentes de terceros y infraestructura delegada. Esa separación ahorra correos y evita que nadie cierre el caso por error.
Terceros y exclusiones
La política debe excluir activos que no controlas, salvo que exista autorización previa. También debe dejar fuera cuentas de correo personales, sistemas internos sin exposición pública y entornos de clientes no cubiertos por contrato.
Una exclusión mal escrita crea el error más frecuente en este punto: alguien prueba un activo ajeno porque “parecía de la agencia”. Después llegan los problemas legales.
Diferencia operativa: un alcance estrecho responde mejor que uno genérico. La agencia puede ampliar el scope más adelante, pero no debería empezar con zonas grises.
Organiza el flujo interno y evita cuellos de botella
La política solo funciona si el reporte entra en un flujo real. Publicar un email sin dueño ni horario de revisión no sirve de mucho.
Canal de reporte oficial
La agencia debe publicar un canal único y estable. Puede ser un correo como [email protected], un formulario web o ambos.
El correo funciona mejor para equipos pequeños. El formulario ayuda si quieres recoger campos mínimos y filtrar ruido. La forma rápida es usar solo correo. La forma correcta es combinar correo y formulario con acuse automático.
ISO/IEC 29147 recomienda definir un canal claro, un contacto responsable y un proceso de respuesta para la divulgación coordinada.
Triage y validación inicial
El triage inicial debe verificar tres cosas: si el activo entra en alcance, si la prueba descrita es aceptable y si el impacto parece real.
Este paso tarda entre 10 y 20 minutos cuando el reporte llega bien escrito. Tarda mucho más si el remitente manda capturas sueltas, sin fechas ni pasos reproducibles.
Escalado a seguridad, desarrollo y legal
La política necesita una matriz de escalado. Seguridad valida el reporte. Desarrollo confirma el impacto técnico. Legal entra si hay acceso a datos, abuso de sistemas o posible incumplimiento contractual.
Un caso habitual: un bug de autenticación parece leve hasta que se ve que afecta a cuentas con permisos de edición. Ahí el caso sube de severidad y se prioriza distinto.
Cierre y confirmación al reportero
El cierre debe incluir confirmación de corrección, explicación breve y, si procede, fecha de publicación coordinada. No hace falta escribir un informe largo. Hace falta cerrar bien.
Si el reportero no recibe una confirmación útil, la política queda a medias.
En la imagen de más abajo se aprecia claramente la diferencia entre un flujo con acuse y otro sin dueño asignado.
Fija SLA, severidad y tiempos de respuesta
El SLA interno convierte la política en algo medible. Sin tiempos, el texto queda bonito y poco útil.
Acuse de recibo y triage
El acuse de recibo debería salir en menos de 24 horas laborables. El triage inicial, en 1 a 3 días laborables, suele ser un plazo razonable para agencias pequeñas o medianas.
El plazo de respuesta más útil no es el más corto, sino el que el equipo puede cumplir siempre.
Matriz de severidad
La severidad ayuda a decidir qué va primero. Una vulnerabilidad crítica con acceso remoto no espera lo mismo que un fallo informativo sin explotación práctica.
| Severidad |
Ejemplo |
Acuse |
Triage |
Acción |
| Crítica |
Ejecución remota o fuga de datos |
24 h |
24-48 h |
Escalado inmediato |
| Alta |
Escalada de privilegios |
24 h |
1-3 días |
Asignación prioritaria |
| Media |
CSRF o XSS con poco impacto |
48 h |
3-5 días |
Plan de corrección |
| Baja |
Cabeceras faltantes o hardening menor |
48 h |
5-7 días |
Cola de mejora |
Compromisos de resolución
Conviene prometer ventanas realistas, no heroicidades. Una corrección crítica puede requerir hotfix, revisión, despliegue y validación. Eso tarda más de lo que parece si hay varios entornos.
La agencia puede prometer una primera mitigación rápida y reservar la corrección completa para el ciclo normal. Esa fórmula funciona bien cuando el parche necesita pruebas antes de salir a producción.
Plazo orientativo: una agencia pequeña suele necesitar entre 1 y 3 días laborables para cerrar el triage; una mediana, entre 24 y 48 horas.
Marca pruebas permitidas y bloquea las invasivas
El apartado de pruebas evita discusiones inútiles. También protege al equipo y al cliente cuando el reportero se pasa de listo.
Pruebas autorizadas
La política puede permitir enumeración básica, prueba de login, verificación de cabeceras, análisis de versionado y reproducción controlada de fallos. Eso basta para validar la mayoría de avisos.
Lo normal es aceptar pruebas que no dañen datos, no interrumpan servicio y no afecten a terceros. Si el investigador necesita más, debe pedir permiso antes.
Pruebas prohibidas
Deben quedar fuera la denegación de servicio, la exfiltración de datos, el acceso a cuentas de terceros, la persistencia de cambios y cualquier prueba destructiva.
Cuidado con una zona gris frecuente: el acceso a un panel no autoriza a exportar información real. Ese matiz evita muchos sustos (y no siempre se escribe claro).
Datos sensibles y explotación
La política debe prohibir la publicación de credenciales, datos personales o capturas con información sensible salvo lo justo para probar el fallo.
La prueba debe demostrar el problema, no convertirlo en incidente.
Publica una plantilla editable lista para usar
La plantilla ahorra tiempo y reduce errores. También evita que el texto salga distinto en cada revisión.
Encabezado y propósito
Usa un encabezado corto y claro. El lector debe entender en dos líneas qué cubre la plantilla y cómo usarla.
Ejemplo de texto base:
Política de divulgación de vulnerabilidades
Esta política describe cómo reportar vulnerabilidades de buena fe sobre los activos cubiertos por [Nombre de la Agencia].
Incluye al menos correo, horario de atención, tiempo de acuse y canal alternativo si el principal falla. Si el formulario web existe, añade una confirmación automática.
Contacto de seguridad: [[email protected]]
Horario de revisión: [Lunes a viernes, 9:00 a 18:00 CET]
Acuse de recibo: [menos de 24 horas laborables]
Canal alternativo: [formulario web / teléfono interno / PGP]
Texto de alcance y exclusiones
La plantilla debe distinguir activos cubiertos, activos excluidos y terceros. Esa parte conviene escribirla con nombres reales, no con frases vagas.
Activos cubiertos: [dominios, subdominios, apps, plugins propios, temas propios]
Exclusiones: [infraestructura de terceros, entornos no autorizados, cuentas internas no públicas]
SLA y límites
Añade plazos concretos y un criterio de severidad. Si el equipo no puede cumplir un plazo, no lo publique.
SLA interno:
- Acuse: 24 horas laborables
- Triage: 1 a 3 días laborables
- Crítica: escalado inmediato
- Alta: prioridad alta
- Media y baja: cola de trabajo
Declaración de buena fe
Incluye una cláusula sencilla. Debe pedir respeto por la continuidad del servicio y por los datos de terceros.
La agencia tratará de buena fe los reportes enviados de forma responsable. Pedimos no acceder, modificar ni divulgar datos reales más allá de lo necesario para demostrar el fallo.
Ejemplo de correo inicial
Aquí tienes un texto que puede copiarse tal cual:
Asunto: Reporte de vulnerabilidad recibido
Gracias por el aviso. Hemos recibido su reporte y lo revisaremos en el plazo indicado en nuestra política.
Si necesita aportar más contexto, responda a este hilo con pasos de reproducción, impacto observado y activo afectado.
Activo afectado
Descripción del fallo
Pasos de reproducción
Impacto observado
Pruebas adjuntas
Correo de contacto
Confirmación de buena fe
Plantilla editable para publicar en una agencia
Valida el marco legal y aprueba el texto
La revisión legal no necesita un tratado. Necesita que el texto no choque con obligaciones reales en España y la Unión Europea.
RGPD y LOPDGDD
Si el reporte puede exponer datos personales, la política debe dejar claro qué hacer con ellos y quién los trata. La AEPD publica criterios útiles sobre minimización, seguridad y tratamiento responsable.
La Agencia Española de Protección de Datos insiste en limitar el acceso a datos personales al mínimo necesario para resolver el incidente.
ENS, NIS y marcos técnicos
Si la agencia trabaja con clientes del sector público o con servicios críticos, conviene revisar el ENS y la Directiva NIS. No hace falta convertir la política en un documento legal. Sí hace falta no contradecir esos marcos.
Para la parte técnica, ISO/IEC 29147 e ISO/IEC 30111 ayudan a ordenar divulgación y gestión de vulnerabilidades. El INCIBE también publica materiales prácticos que encajan bien con agencias y proveedores de mantenimiento.
Aprobación por seguridad y comunicación
La política no debe salir sin revisión de seguridad y de comunicación. Seguridad valida el proceso. Comunicación revisa el tono público. Legal revisa el texto sensible.
Un caso habitual: una política técnicamente correcta fracasa porque el correo de contacto no se vigila o porque el texto promete más de lo que el equipo puede cumplir. Ese fallo se evita antes de publicar.
Esta política no sustituye un programa formal de bug bounty con recompensas ni una plataforma especializada. Tampoco encaja bien si la agencia no gestiona activos propios o no quiere recibir reportes públicos. En esos casos, el encaje cambia y conviene otro modelo operativo.
Aunque a menudo se usan como sinónimos, no es lo mismo una VDP, una responsible disclosure y un programa de bug bounty. La VDP es una política de divulgación responsable y divulgación coordinada para recibir vulnerabilidades de buena fe y gestionarlas internamente, normalmente sin recompensa económica. Responsible disclosure suele referirse al mismo enfoque, con énfasis en la comunicación responsable entre investigador y organización. Bug bounty, en cambio, añade incentivos o pagos y suele requerir reglas más amplias, más control de alcance y una operativa de triage de seguridad más madura.
Para una agencia, empezar con una VDP suele ser más realista que lanzar un bounty, sobre todo si el volumen de reportes es bajo y la coordinación con terceros ya consume bastante capacidad.
Antes de publicar la política, conviene pasar por un checklist de cumplimiento legal y aprobación interna. Ese control mínimo debería confirmar que el alcance es correcto, que no se prometen plazos imposibles, que el texto no contradice el RGPD ni la LOPDGDD, y que existe un responsable real para el escalado interno. También debe revisarlo seguridad, comunicación y, cuando aplique, legal, especialmente si la política afecta a clientes, terceros o sistemas con datos personales. En agencias que trabajan con WordPress, esta validación evita conflictos cuando un reporte toca un proveedor de hosting gestionado, un plugin SaaS o un servicio externo.
La revisión final no solo reduce errores legales: también protege la reputación y evita que una mala formulación convierta una divulgación coordinada en un incidente público.
Preguntas frecuentes
¿Una VDP es lo mismo que un bug bounty?
No, una VDP no paga recompensas por defecto. La política de divulgación de vulnerabilidades para agencias puede existir solo para recibir reportes de buena fe y coordinar su corrección. El bug bounty añade incentivos económicos y suele apoyarse en plataformas o reglas más amplias. Para muchas agencias, la VDP cubre mejor el primer paso.
¿Qué activos debe incluir el alcance?
Debe incluir solo lo que la agencia controla o supervisa. Eso suele abarcar dominios, subdominios, aplicaciones, plugins propios, temas propios y ciertos entornos de prueba. También debe listar exclusiones, sobre todo si hay hosting, CDN o servicios de terceros que no gestionan directamente.
¿Qué SLA interno funciona mejor para una agencia
Uno simple y cumplible. El acuse en menos de 24 horas laborables y el triage en 1 a 3 días suele funcionar bien. Si el equipo es muy pequeño, conviene decirlo con claridad y prometer menos, no más. La política falla cuando promete rapidez y luego nadie responde.
¿Qué pruebas puede hacer un investigador sin
Las pruebas no invasivas suelen ser aceptables. Eso incluye enumeración básica, reproducción controlada, revisión de cabeceras y validación de un fallo sin tocar datos reales. La política debe prohibir DoS, exfiltración, persistencia y cambios destructivos. Esa línea evita problemas técnicos y legales.
¿Cómo se gestiona un reporte que afecta a un
Se asigna primero al responsable del activo y luego al proveedor, si procede. La agencia no debe prometer que corrige algo que no controla. Lo correcto es validar el impacto, avisar al cliente afectado si toca, y coordinar con el fabricante o el hosting cuando el fallo venga de fuera.
¿Hace falta revisión legal antes de publicar la
Sí, aunque sea breve. Legal debe revisar exclusiones, tratamiento de datos, límites de pruebas y lenguaje sobre buena fe. Seguridad y comunicación también deben aprobar el texto. Esa revisión previa evita promesas imposibles y reduce fricción cuando llegue el primer aviso real.
¿Dónde encaja la divulgación coordinada en
Encaja en cualquier agencia que gestione sitios activos y reciba avisos de fallos. WordPress Security Team, INCIBE y marcos como ISO/IEC 29147 ayudan a estructurar el proceso. La política de divulgación de vulnerabilidades para agencias funciona mejor cuando el flujo interno ya sabe quién responde, quién escala y quién cierra.
Qué hacer ahora con tu política
Redacta una versión corta, clara y operativa. Luego valida el alcance, fija el SLA interno y añade exclusiones reales.
El texto perfecto no sirve si nadie lo usa. El texto útil, sí. Publica primero una versión simple y ajústala cuando el proceso ya funcione con casos reales.
Plan práctico: publica hoy el canal de contacto, el alcance y el SLA. El resto puede afinarse en una segunda revisión, pero no dejes el proceso sin dueño.
