El 12 de agosto de 2026, MyDr sp. z o.o., proveedor polaco de software de historia clínica electrónica, confirmó en [su propia página de incidentes](https://pro.mydr.pl/portal-info) que «fue objeto de una acción delictiva externa y deliberada» que afecta a «parte de los datos». Por separado, los atacantes dijeron al medio polaco de seguridad Zaufana Trzecia Strona que tienen 18.814.422 números PESEL únicos. MyDr no confirma ni esa cifra ni ninguna otra. Lo que MyDr comparte con otras cuatro brechas importantes en tres continentes es algo más concreto y más fácil de arreglar que cualquiera de las causas raíz: cuando alguien de fuera quiso avisar de algo, no había una vía habilitada para hacerlo. Un programa de divulgación de vulnerabilidades (VDP) no habría frenado ninguna de estas cinco brechas. Este artículo va de quién se entera primero y de cuánto tarda en enterarse. ## Qué pasó en MyDr y las tres cifras que no cuadran MyDr desarrolla software de historia clínica y de gestión de consultas para clínicas polacas, y el grupo Docplanner (ZnanyLekarz) anunció su adquisición el 9 de enero de 2023. Hoy circulan tres cifras, y no coinciden entre sí. - **Lo que afirman los atacantes:** 18.814.422 números PESEL únicos y unos 2,5 TB. Zaufana Trzecia Strona señala que no pudo verificar ninguna de las dos cosas. - **Lo que dice el Gobierno:** el viceprimer ministro Krzysztof Gawkowski declaró el 12 de agosto que se robaron cerca de 19 millones de registros, «cosa que la propia empresa confirma» ([Bankier](https://www.bankier.pl/wiadomosc/Cyberatak-na-MyDr-Gawkowski-Mozliwy-wyciek-danych-blisko-19-mln-Polakow-9181057.html), 2026). - **Lo que confirma MyDr:** nada. Su página, actualizada a las 18:35 CET de ese mismo día, dice que la empresa no puede confirmar la cantidad ni el tipo de datos expuestos, y describe los datos afectados como «muy probablemente históricos, de 2024 y años anteriores». Son dos fuentes primarias publicadas con horas de diferencia que se contradicen en el dato central. Hoy no existe ningún recuento confirmado. Zaufana Trzecia Strona sí verificó parte de la muestra de los atacantes, incluido el registro de un político de primera fila y tres aciertos en una prueba con cinco PESEL. Eso corrobora que los atacantes tienen datos reales compatibles con los de MyDr. No corrobora los 18,8 millones. La causa raíz la afirman los atacantes y está sin verificar: un fallo XXE en el tratamiento de certificados que desemboca en ejecución de código, una clave de API de GitHub robada y, después, AWS. MyDr no ha publicado ningún detalle técnico y la atribución está deliberadamente enturbiada, así que no procede señalar a ningún grupo ni a ningún país. Las fechas de detección se desconocen, porque la empresa dice que no puede darlas mientras dure la investigación, así que tampoco procede inferir ningún tiempo de permanencia. Lo importante es el orden de los acontecimientos. El 5 de agosto los atacantes enseñaron a los periodistas una captura de un mensaje que, según ellos, habían enviado al CEO de la matriz de la plataforma, con un enlace a un PDF protegido por una contraseña que era el propio PESEL del CEO. El 8 de agosto contactaron con la prensa. La primera declaración de MyDr llegó el 10 de agosto, el mismo día en que esos periodistas publicaron. Los pacientes polacos todavía no pueden comprobar si están afectados. MyDr es encargado del tratamiento según el RGPD, así que el comunicado de la UODO del 12 de agosto sitúa el deber de informar a las personas en los responsables del tratamiento: las miles de clínicas que usaban el software. Y el portal nacional de comprobación de fugas indica que los datos de MyDr no se han cargado en él. En cuanto a avisar de un fallo: sondeado el 12 de agosto de 2026, `mydr.pl/.well-known/security.txt` redirige a una página genérica y `pro.mydr.pl` devuelve un 404. El único archivo RFC 9116 del grupo está en la marca de consumo `znanylekarz.pl`: 44 bytes, una sola línea `Contact:` y ningún campo `Expires`, obligatorio según el RFC. Es una observación sobre un canal, no una afirmación sobre la causa. No hay indicio alguno de que alguien intentara siquiera avisar de nada. ## ¿Cómo se enteran las empresas de que han sufrido una brecha? En 2025, solo el **52 %** de las organizaciones fue la primera en detectar la actividad maliciosa. Al **34 %** se lo comunicó una entidad externa, como las fuerzas del orden o un CERT, y al **14 %** se lo dijo el propio atacante, normalmente en una nota de rescate ([Mandiant M-Trends 2026](https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/), 2026). El tiempo de permanencia mediano fue de 14 días: **9 días** cuando la detección fue interna y **25 días** cuando lo encontró antes alguien de fuera, más del doble de los 11 del año anterior. Esa diferencia es lo que cuesta no tener por dónde recibir el aviso. ## Change Healthcare: 190 millones de personas y una migración a medias El formulario 10-K del ejercicio 2024 de UnitedHealth habla de «aproximadamente 190 millones» de personas. La cifra mayor, 192,7 millones, procede del portal de brechas de la OCR del HHS y de la prensa sectorial, no de ninguna presentación ante la SEC, y el recuento comunicado a la OCR creció desde una cifra provisional de 500 personas a lo largo de unos dieciocho meses. La causa raíz está en la declaración jurada del CEO, Andrew Witty: el 12 de febrero de 2024 unos delincuentes usaron credenciales comprometidas para llegar a un portal Citrix que «no tenía autenticación multifactor», se movieron lateralmente y exfiltraron datos entre el 17 y el 20 de febrero. El ransomware se desplegó el 21 de febrero, nueve días después de la entrada. Varios medios señalaron a CitrixBleed; ninguna fuente primaria lo respalda. Preguntada por qué un servidor expuesto a internet no tenía MFA, UnitedHealth respondió al Senado que «el servidor en cuestión era un servidor heredado de Change Healthcare, y nuestro equipo estaba trabajando para ponerlo a la altura de los estándares de UHG». La adquisición se había cerrado dieciséis meses antes. El formulario 8-K con el punto 1.05 se presentó un día después de la detección; las cartas individuales a los afectados no empezaron a enviarse hasta finales de julio de 2024, unos cinco meses después de que los datos salieran. Había un canal y, aun así, no habría servido de nada. La política de notificación de vulnerabilidades de UnitedHealth, activa desde al menos 2019, no ofrecía recompensas, ni puerto seguro (Safe Harbor), ni un SLA de respuesta. Prohibía «el escaneo o las pruebas activas de vulnerabilidades», excluía la «vulneración de “buenas prácticas”» y declaraba que la empresa «no divulgará, comentará ni confirmará problemas de seguridad». Una pasarela expuesta a internet y sin MFA es justo lo que un investigador solo puede detectar con un escaneo activo, y justo lo que quien hace el triaje puede cerrar como incumplimiento de buenas prácticas. ## Salesloft Drift: la brecha que un programa de divulgación no habría detectado Va aquí precisamente porque juega en contra del argumento. Entre marzo y junio de 2025, un actor identificado como UNC6395 controló la cuenta de GitHub de Salesloft y desde ahí saltó al entorno de AWS de Drift, donde se guardaban los tokens OAuth de los clientes, y usó esos tokens legítimos para alcanzar las instancias de Salesforce de esos clientes. El Google Threat Intelligence Group afirma que el problema «no procede de una vulnerabilidad de la plataforma central de Salesforce». Salesloft nunca ha divulgado cómo se hicieron con la cuenta de GitHub. El MFA y la supervisión de inicios de sesión quedaron sorteados de entrada: la aplicación estaba autorizada y los tokens eran auténticos. Lo que buscaba el atacante eran credenciales pegadas en tickets de soporte: Cloudflare encontró 104 tokens activos de su propia API dentro del texto de los casos exfiltrados y los rotó todos; el corpus entero había salido en 3 minutos y 22 segundos. Entre el primer acceso a GitHub y la divulgación del 20 de agosto de 2025 pasaron unos cinco meses; entre el final de la exfiltración observada y la revocación de los tokens, solo dos días. **Un programa de divulgación de vulnerabilidades no habría detectado esto.** El secuestro de una cuenta de GitHub y un almacén centralizado de tokens dentro del propio AWS de un proveedor no son observables desde fuera, y las debilidades aledañas son decisiones de arquitectura que la mayoría de los VDP dejan fuera de alcance. Compáralo con un fallo que sí encaja en un VDP, del mismo ecosistema y del mismo trimestre. Noma Security encontró ForcedLeak (CVSS 9.4) en Salesforce Agentforce: un dominio caducado que seguía en la lista de permitidos de una CSP y que se podía comprar por unos 5 dólares. Comunicado el 28 de julio de 2025, con acuse de recibo el 31 de julio, corregido el 8 de septiembre y divulgado el 25 de septiembre. Encontrado desde fuera, comunicado, corregido y publicado. ## Free Mobile: 42 millones de euros de multa y cuatro millones de víctimas que ya se habían ido Las deliberaciones de la CNIL de enero de 2026 fijan el alcance confirmado en **24.633.469 contratos**: 19.460.891 de móvil y 5.172.577 de fijo, con nombres, direcciones, fechas de nacimiento e IBAN de los clientes que tenían ambos servicios ([CNIL](https://www.cnil.fr/en/sanction-free-2026), 2026). El atacante llegó a la herramienta de gestión de abonados a través de la VPN de Free Mobile, cuya autenticación la CNIL consideró «insuficientemente robusta» por la ausencia de autenticación de dispositivo y de MFA para los usuarios. La segunda conclusión de la CNIL fue que la empresa no había desplegado medios suficientes para detectar actividad sospechosa en esa VPN, en su red interna ni en la herramienta de abonados. Guardar registros no es un control. La tercera conclusión es la que los fundadores infravaloran. Free Mobile infringió además el artículo 5.1.e por conservar más de quince millones de contratos rescindidos pasados cinco años, y tres millones pasados diez. La aritmética lo delata: 19,46 millones de contratos de móvil expuestos frente a unos 15,51 millones de abonados de móvil activos a 31 de diciembre de 2024. Se expusieron unos cuatro millones de contratos por encima del número de abonados activos. La política de conservación era un control de seguridad, y su ausencia amplió el radio de impacto en millones de personas. El acceso se extendió del 28 de septiembre al 22 de octubre de 2024, y la CNIL deja constancia de que a la empresa la avisó el 21 de octubre un atacante que ya había entrado en sus sistemas. Free notificó a la CNIL dentro del plazo de 72 horas y aun así perdió en el artículo 34, porque la CNIL sostuvo que el correo de notificación no permitía tranquilizar a los millones de personas afectadas. Multas: 27 millones de euros a FREE MOBILE y 15 millones a FREE. Hoy `free.fr` sirve un `security.txt` firmado con PGP, verificado el 12 de agosto de 2026: URL canónica, dos contactos, una fecha `Expires` y una huella OpenPGP. No tiene línea `Policy:`, así que no hay alcance ni puerto seguro. Un buzón no es un programa, y este intruso prefirió irse a un foro delictivo. ## Tea: quien lo encontró fue 4chan, y la corrección llegó después de la publicación Tea Dating Advice confirmó que se accedió a 72.000 imágenes, entre ellas 13.000 selfies de verificación e imágenes de documentos oficiales de identidad ([NBC News](https://www.nbcnews.com/tech/social-media/tea-app-hacked-13000-photos-leaked-4chan-call-action-rcna221139), 2025), y el resto procedente de publicaciones, comentarios y mensajes; el incidente solo afectó a quienes se habían registrado antes de febrero de 2024 ([TechCrunch](https://techcrunch.com/2025/07/26/dating-safety-app-tea-breached-exposing-72000-user-images), 2025). Su notificación al fiscal general de California es más acotada: acceso no autorizado, el 24 de julio de 2025 o en fechas próximas, a una ubicación de almacenamiento con registros de verificación, con indicios de acceso a «la mayoría o posiblemente todos», lo que dejó al descubierto nombres, fechas de nacimiento y números de permiso de conducir y de pasaporte. La causa raíz cabe en la frase que 404 Media citó del mensaje de 4chan que lo desencadenó todo: «Sin autenticación, sin nada. Es un bucket público». Sin credenciales, sin cadena de exploits, solo una URL. Y después, un segundo fallo: una base de datos Firestore de mensajes directos que cualquier usuario autenticado de Tea podía leer. 404 Media habló de más de 1,1 millones de mensajes, contrastados con una muestra; Tea nunca confirmó ninguna cifra y se limitó a decir que se accedió a algunos mensajes. Dos fallos, dos canales, y ninguno de los dos era la empresa. El primero acabó en 4chan un jueves por la noche, y el aviso a los usuarios no llegó hasta el 28 de agosto de 2025: 35 días de intervalo según el registro de California. El segundo acabó en manos de un periodista. El investigador independiente Kasra Rahjerdi encontró la base de datos de mensajes, decidió no publicarla y la canalizó a través de 404 Media hasta Tea, porque ese era el canal que funcionaba. Tea desactivó los mensajes directos dos días más tarde, ya publicado el caso. No ha trascendido ninguna acción sancionadora de un regulador, lo cual es ausencia de anuncio, no prueba de que no haya investigación. ## Los cinco casos, uno al lado del otro | Brecha | Alcance confirmado | Quién se lo dijo primero | Canal para avisar (sondeado el 12 de agosto de 2026) | |---|---|---|---| | **MyDr** (PL, ago. 2026) | Ninguno; los atacantes afirman 18.814.422 PESEL | Los atacantes y, después, los periodistas | Sin `security.txt`; un archivo de 44 bytes no conforme en una marca hermana | | **Change Healthcare** (EE. UU., feb. 2024) | ~190 millones (10-K); 192,7 millones en el portal del HHS | Nadie de fuera; la alarma fue el ransomware | La política de la matriz prohibía el escaneo activo; el sitio devuelve 404 | | **Salesloft Drift** (SaaS, ago. 2025) | No publicado | Se desconoce; ninguna fuente pública nombra a quien lo detectó primero | 404, meta-refresh, soft-404; sin programa público | | **Free / Free Mobile** (FR, oct. 2024) | 24.633.469 contratos (CNIL) | El atacante, el día 23 de una intrusión de 24 días | `security.txt` firmado con PGP, sin línea `Policy:` | | **Tea** (EE. UU., jul. 2025) | 72.000 imágenes, 13.000 de ellas documentos de identidad y selfies | 4chan y, después, un periodista | 404 en ambos dominios | ## Qué tienen en común los cinco **Un proveedor, miles de radios de impacto (3 de 5).** MyDr es encargado del tratamiento para miles de clínicas; Change Healthcare, una cámara de compensación de buena parte de las reclamaciones sanitarias de EE. UU.; Drift, una aplicación instalada dentro de los entornos de Salesforce de centenares de empresas. En los tres casos, la parte comprometida no era aquella cuyos clientes salieron perjudicados. Ahora corre un reloj de 72 horas del artículo 33 para miles de pequeñas clínicas polacas que no tienen visibilidad forense propia. **Datos guardados mucho después de dejar de servir para algo (3 de 5).** Free es el caso probado por el regulador. Tea es el caso de la promesa frente a la práctica: su política de privacidad decía que los selfies de verificación se borraban inmediatamente después de usarse, y 13.000 estaban en un bucket público. MyDr es el caso con reservas. «Muy probablemente históricos, de 2024 y años anteriores» se ofrece para tranquilizar, pero leída como una declaración sobre conservación, la frase dice que había registros históricos todavía alcanzables desde producción. **El aviso llegó de fuera, y nunca de un investigador (4 de 5).** MyDr: los atacantes escribieron al CEO. Free: el intruso puso fin a veintitrés días de silencio. Tea: 4chan y, después, un periodista. Change Healthcare: el propio cifrado. Salesloft: se desconoce, y ese vacío debe seguir siendo un vacío. Las cifras de Mandiant dicen que esta es la tasa base, no una racha de mala suerte. **Los identificadores que no se pueden rotar (3 de 5).** Puedes rotar una contraseña, una clave de API o un token OAuth; Cloudflare rotó 104 en una semana. No puedes rotar un PESEL, un IBAN, un número de pasaporte ni una fecha de nacimiento. El consejo oficial polaco se reduce hoy a bloquear tu PESEL en mObywatel y esperar a que tu clínica te escriba. Cada año de más que se conservan los datos es otro año de identificadores permanentes esperando en un sistema al que alguien acabará por llegar. **El activo heredado (2 de 5).** UnitedHealth cerró la adquisición de Change Healthcare en octubre de 2022, y en febrero de 2024 la pasarela sin fortificar seguía en la lista de migración. MyDr se adquirió en enero de 2023, y el único archivo RFC 9116 del grupo está en otra marca y con otra dirección de contacto. La integración corporativa y la integración de la superficie de seguridad son proyectos distintos, y el segundo suele perder. **No había adónde enviar un informe (5 de 5).** Es el único rasgo que se cumple en los cinco, y dos de ellos muestran por qué publicar una página no es la meta. Change Healthcare demuestra que un canal no basta: una política que prohíbe el escaneo y excluye los hallazgos sobre buenas prácticas filtra justo la clase de informe que importaba. Salesloft demuestra que un canal no siempre es pertinente. Lo que sí te da un canal está en palabras de la propia Verizon sobre los almacenes de datos expuestos: «lo más habitual es que los descubran investigadores de seguridad, que después intentan avisar si consiguen determinar de quién son los datos. Lo que no sabemos es con qué frecuencia otras personas, menos cívicas, se han topado con esos mismos datos, han hecho una copia y se han marchado sin decir nada» ([Verizon 2026 DBIR](https://www.verizon.com/business/resources/T1ae/reports/2026-dbir-data-breach-investigations-report.pdf), 2026). El bucket de Tea es ese párrafo con nombre propio. Sin canal, las opciones que le quedan a quien encuentra el fallo entrañan un riesgo personal real. Unos estudiantes y un profesor de Malta que escribieron a una empresa por unas vulnerabilidades en octubre de 2022 sufrieron una redada de la policía armada tres semanas después, y no fueron indultados hasta julio de 2025. Si tu única vía de entrada es un buzón de soporte y un equipo legal, ya has publicado una política: la equivocada. Más sobre esto en [puerto seguro y amenazas legales a los investigadores de seguridad](/blog/safe-harbor-legal-threats-security-researchers-vdp). ## Dónde un programa de divulgación ya es ley y dónde no Conviene ser preciso aquí, porque la mayor parte de la cobertura no lo es. **Cyber Resilience Act de la UE (Reglamento 2024/2847).** El anexo I, parte II, punto 5 exige a los fabricantes de productos con elementos digitales «aplicar y hacer cumplir una política de divulgación coordinada de vulnerabilidades». Fíjate en el verbo: una página publicada, por sí sola, no lo cumple. El reloj del artículo 14 (alerta temprana en 24 horas, notificación en 72 horas e informe final en 14 días para las vulnerabilidades activamente explotadas) se aplica desde el 11 de septiembre de 2026, y el reglamento en su totalidad desde el 11 de diciembre de 2027. Obliga a los fabricantes que introducen productos en el mercado de la UE, así que una empresa web puramente SaaS suele quedar fuera del ámbito de aplicación. Nuestro [desglose de las obligaciones de divulgación del CRA](/blog/eu-cyber-resilience-act-mandatory-vulnerability-disclosure) entra en el detalle. **NIS2 (Directiva 2022/2555).** El artículo 12 obliga a los Estados miembros y a ENISA, no a las empresas una por una. La reforma polaca de transposición, la enmienda a la KSC, entró en vigor el 3 de abril de 2026, unos diecisiete meses después del plazo de la UE, con un registro que vence el 3 de octubre de 2026. El incidente de MyDr cae dentro de esa ventana, antes de que aprieten los plazos de cumplimiento y de sanción. **PSTI del Reino Unido (SI 2023/1007).** Exigible desde el 29 de abril de 2024 para los productos conectables. El anexo 1 exige un contacto publicado y una declaración de los plazos en que quien informa recibirá el acuse de recibo y las actualizaciones de estado. Esa declaración debe estar accesible sin solicitud previa, ser gratuita y no exigir los datos personales de esa persona. Ese último requisito descarta los formularios con registro previo y las páginas de contacto tras un inicio de sesión. **CISA BOD 20-01.** Obligatoria para las agencias civiles federales de EE. UU. desde 2020: una política en la ruta fija `/vulnerability-disclosure-policy`, con alcance declarado, pruebas permitidas y una indicación clara de que los informes pueden ser anónimos. La plataforma de VDP de CISA registró más de 12.000 envíos en 51 programas de agencias de forma acumulada hasta 2023, con más de 2.400 divulgaciones válidas. **Lo que no es obligatorio.** NIS2 no obliga a las empresas a operar un VDP, y PCI DSS 4.0 tampoco; la guía del PCI SSC dice que los programas de divulgación «pueden ayudar» con los requisitos 6.3.3 y 12.10.1. En la contratación pública federal estadounidense no hay obligación en el FAR. El vehículo es la H.R. 872, aprobada por la Cámara de Representantes el 3 de marzo de 2025 y todavía sin promulgar a 12 de agosto de 2026. Los números no esperan a la ley. IBM situó el coste medio mundial de una brecha en un récord de 4,99 millones de dólares en 2026, un 12 % más ([IBM Cost of a Data Breach 2026](https://www.ibm.com/reports/data-breach)). HackerOne pagó 81 millones de dólares en recompensas repartidas entre 1.950 programas en el año cerrado a 30 de junio de 2025, pero los 100 programas más grandes se llevaron 51 millones, lo que deja unos 16.000 dólares al año para un programa corriente. Un programa sin recompensas cuesta todavía menos. Y casi nadie publica un contacto: un rastreo de Tranco revisado por pares encontró `security.txt` en el 34,0 % de los 100 dominios más visitados, pero solo en el 1,0 % del millón de dominios más visitados en un escaneo de enero de 2023 (Hilbig et al., ACM DTRAP), y apenas en el 1,25 % de ese mismo millón en enero de 2025, con un 44 % de los archivos existentes conformes al RFC (URIports, 2025). ## Qué publicar esta semana Nada de esto necesita presupuesto para recompensas ni un contrato con una plataforma. El mínimo que, en los cinco casos, le habría dado a quien encontró algo un sitio al que acudir: 1. **Un `security.txt` conforme al RFC 9116** con un `Contact:` que funcione, una fecha `Expires:` y una línea `Policy:`. `Expires` es obligatorio, y detalles como ese son la razón por la que la mayoría de los archivos publicados no cumplen la norma. 2. **Una página de política** que declare alcance, pruebas permitidas y puerto seguro en lenguaje llano. La matriz de Change Healthcare prohibía justo el escaneo que habría hecho falta; Free tiene un buzón sin política alguna. 3. **Un compromiso de acuse de recibo.** Buena práctica, no obligación legal: di en cuánto tiempo confirmarás la recepción, y cúmplelo. 4. **Un responsable con nombre y apellidos, y una cola.** El triaje de los informes que caen en un buzón compartido lo hace quien esté menos ocupado, es decir, nadie. 5. **Una cronología que puedas exportar.** Cuando un regulador o un periodista pregunte qué sabías y cuándo, «lo gestionamos de forma responsable» no es una prueba. Una cronología por informe sí lo es. La versión paso a paso: [cómo montar un programa de divulgación de vulnerabilidades](/blog/how-to-set-up-vulnerability-disclosure-program). ## Gestionar la recepción sin tener que construirla Publicar un contacto lleva una tarde. Gestionar lo que llega es la parte que falla en silencio, porque una cola de divulgación se comporta como cualquier otra cola: se atasca, el reloj corre y nadie lo nota hasta que lo nota alguien de fuera. El módulo CSIRT de Kit es la capa operativa para eso y nada más. Genera el `security.txt` y aloja un portal de seguridad público con tu alcance publicado al lado, de modo que los objetivos dentro y fuera de alcance quedan declarados y no sobreentendidos. Los informes que entran se validan contra ese alcance, se deduplican y arrancan un reloj de SLA con objetivos de acuse de recibo y de resolución por nivel de severidad, más un seguimiento de los informes en riesgo de incumplir el plazo, para que un compromiso roto aflore antes de que quien informa escale el asunto. Los investigadores tienen perfiles persistentes y karma, así que quien informa una y otra vez con hallazgos reveladores no queda atrapado detrás del ruido. Las recompensas son opcionales: la matriz de severidad, la votación de propuestas, el libro mayor y el traspaso al pago están ahí si pagas, y latentes si no. Cada informe lleva una cronología exportable. Los límites importan tanto como las funciones. Kit no habría evitado ninguna de estas cinco brechas. No es EDR, ni segmentación, ni MFA, y no habría sacado a la luz el secuestro de la cuenta de GitHub de Salesloft. No presenta nada en la plataforma de ENISA ni hace por ti las notificaciones de los artículos 33 y 34, y no es asesoramiento jurídico. La afirmación honesta es más modesta: en cuatro de estos cinco casos, el primero en saberlo no fue la empresa, y un canal publicado cambia quién se entera primero.

Publica un contacto y una política esta semana. El módulo CSIRT de Kit te da un portal de seguridad público, un security.txt generado, validación de alcance, seguimiento de SLA y una cronología exportable por informe.

Empieza tu prueba gratuita

Cinco empresas, tres continentes, cinco causas raíz distintas. Lo único que compartían las cinco es que una persona de fuera que quería decirles algo no tenía una vía habilitada para hacerlo. Eso no es un déficit de madurez ni un problema de presupuesto. Es una interfaz que falta, y es la más barata de tu hoja de ruta.