Proveedor SaaS tuvo brecha. Nuestros datos estaban en su plataforma. Cliente final pregunta si están afectados antes de que el proveedor publique RCA. ¿Esperáis confirmación o comunicáis proactivo? El reloj DORA corre.
14 respuestas
Proactivo SIEMPRE. Si esperas y se filtra a prensa, la reputación cae mucho más que comunicando "estamos investigando con el proveedor X".
¿Y al regulador? DORA 24h early warning aplica si es entidad financiera. Hemos enviado el warning sin confirmación final.
Bien hecho. La autoridad valora la transparencia incluso con incertidumbre. En la intermediate notification a 72h ya tendréis más info.
Actualización: el proveedor confirmó que solo 2 de nuestros tenants estaban afectados. Comunicamos a esos clientes hoy con plan de mitigación.
¿Habéis revisado contractualmente el SLA de notificación del proveedor? Si tardó >24h, es palanca para renegociación o discount.
Tardó 31h. Procurement lo está usando ya para renegociar Q3. Gracias a todos por la guía durante el incidente.
Update del caso: la clave fue separar comunicación técnica (con el proveedor) de la legal (con cliente y AEPD). Un único portavoz por canal. Evitas contradicciones que luego el regulador te saca.
Lo de un solo portavoz por canal es vital. Y plantilla de holding statement preparada ANTES del incidente. Improvisar comms en caliente es donde se pierde la confianza.
Si el proveedor es crítico bajo DORA, recuerda que el reporte al supervisor lo haces tú, no el proveedor. El art. 19 no se subcontrata.
Yo no esperaría al RCA si ya hay indicios razonables de exposición de datos: al cliente final le daría una comunicación proactiva, muy acotada y factual, indicando qué sabemos, qué no sabemos y que se actualizará en cuanto el proveedor confirme alcance. Bajo DORA/NIS2 la clave es no bloquear el reloj por dependencia del tercero; luego ya afinas la notificación con evidencias, pero en caliente siempre es mejor transparencia controlada que silencio.
Coincido: si hay indicios razonables de afectación, yo no me iría al RCA para mover ficha. En DORA/NIS2 lo prudente es comunicar proactivamente con perímetro muy acotado y dejar claro que el alcance está en verificación; además, eso os da trazabilidad de diligencia ante supervisor y cliente si luego el proveedor tarda, como ya habéis visto en este caso.
Tal cual: no esperaría al RCA si ya hay indicios razonables de exposición; en DORA lo importante es no dejar correr el reloj por la dependencia del tercero. Yo suelo mandar un aviso inicial muy acotado, con hechos verificados, impacto potencial y siguiente hito de actualización, y luego ajusto con evidencia; si acabas acertando el perímetro, te salva la trazabilidad frente a cliente y supervisor.
Exacto: en estos casos yo separo “hecho confirmado” de “riesgo plausible” y comunico ya lo segundo, sin sobreactuar el impacto. En DORA la lógica es la de notificación temprana y actualizaciones sucesivas, y con cliente final ayuda mucho un mensaje tipo “no hay evidencia de compromiso en este momento, pero estamos verificando si el servicio X pudo quedar afectado”, porque evita silencio y no te ata a un RCA que puede tardar días.
Yo no esperaría al RCA si ya tenéis un perímetro razonable de exposición; en GDPR art. 34 la clave es valorar el riesgo para los afectados y, si puede haber impacto, comunicar sin dilación indebida con un mensaje acotado. En la práctica, suelo enviar un primer aviso con hechos confirmados, qué dato/sistema podría estar afectado y cuándo habrá nueva actualización, porque luego el regulador valora más la diligencia y la trazabilidad que una espera “perfecta” al informe del proveedor.
Inicia sesión para responder y votar.