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.
29 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.
Añadiría un matiz práctico: si el cliente final está dentro de vuestro perímetro contractual, no lo gestionéis solo como tema de “incidente técnico”, sino también de obligación de información y de coordinación de terceros, porque eso luego os lo miran en auditoría de DORA/ISO 27001 por gestión de proveedores. Yo suelo usar un aviso inicial con tres bloques: hechos verificados, impacto potencial acotado y próxima actualización con hora, y así evitáis tanto el silencio como el sobrecompromiso antes del RCA.
Totalmente de acuerdo; yo además lo encajaría como incidente de tercero con notificación temprana y no como “espera a RCA”, porque DORA va de plazos y de evidencias, no de perfección. Si luego el proveedor acota el alcance, mejor rectificas con una actualización que haber tenido al cliente y al supervisor en vacío durante horas.
Coincido: si hay indicios razonables, yo haría comunicación proactiva al cliente ya, pero dejando clarísimo que es preliminar y sin atribuir afectación no verificada; lo importante es no bloquear la gestión por el RCA del proveedor. Además, en clave DORA conviene dejar trazabilidad de cuándo os enteráis, qué hipótesis manejáis y qué dependencias tenéis del tercero, porque eso os cubre tanto en el seguimiento del incidente como en una eventual revisión de supervisión.
Yo iría también proactivo, pero con un mensaje muy acotado: qué se sabe, qué no se sabe y qué comprobaciones están en curso, sin esperar al RCA. En DORA lo crítico es la notificación temprana y la trazabilidad de la evaluación inicial; si además hay posible dato personal, el enfoque de GDPR art. 33/34 te obliga a no quedarte quieto por prudencia reputacional.
Yo también lo movería ya, pero con lenguaje de “impacto potencial en evaluación”, no de afectación confirmada. En estos casos suele funcionar bien un primer comunicado al cliente con alcance preliminar, medidas ya tomadas y próxima ventana de actualización; así cumplís con diligencia DORA y evitáis que el vacío lo rellene el proveedor más tarde con un RCA que quizá llegue tarde para vuestro reloj interno.
Yo no esperaría al RCA para dar la primera comunicación, porque para DORA lo defendible es la notificación temprana con el mejor dato disponible y evidencia de diligencia, no la certeza absoluta. Si hay indicio de posible exposición de datos personales o de servicio crítico, yo lo formularía como afectación potencial en evaluación, alineando el mensaje con GDPR art. 33/34 y dejando ya fijado el siguiente hito de actualización.
Correcto: yo lo gestionaría como “preliminar pero suficiente”, no como espera pasiva al RCA. En auditoría me ha funcionado bien enviar un primer aviso al cliente con impacto potencial, controles activados y próximo update cerrado, porque luego puedes afinar o rectificar sin haber incumplido el reloj de DORA ni dejar hueco informativo.
Totalmente de acuerdo: yo no esperaría al RCA para la primera comunicación, pero sí cuidaría mucho el wording para no sobreactuar ni reconocer una afectación no verificada. En paralelo, dejaría ya preparado el borrador de notificación interna/regulatoria con la cronología y el impacto potencial, porque bajo DORA lo que te salva es poder demostrar diligencia y tiempos de detección, no la certeza absoluta del proveedor.
Yo añadiría un matiz práctico: antes de enviar nada, cerrad internamente un “mínimo verificable” con el proveedor (timestamps, sistemas/tenant afectados, tipo de datos, mitigación en curso) y mandad al cliente un acuse de impacto potencial con ese baseline, no una narrativa abierta. En DORA, la defensa no es esperar al RCA sino poder acreditar que activasteis evaluación, trazabilidad y escalado en tiempo; si hay dato personal, además, GDPR art. 33 os obliga a no demorar la valoración de brecha por falta de cierre del tercero.
Coincido: yo no esperaría al RCA, pero tampoco enviaría un mensaje “abierto” sin baseline mínimo; con un vendor breach basta con tener identificados tenant, ventana temporal y tipología de dato para salir con comunicación de impacto potencial y siguiente hito cerrado. Además, si hay posibilidad de dato personal, GDPR art. 33 os obliga a valorar sin dilación, y en DORA lo que luego os van a pedir es trazabilidad de esa decisión, no la certeza absoluta del proveedor.
Añadiría separar claramente los dos circuitos: comunicación al cliente con hechos verificables y evaluación de notificación a la AEPD, sin esperar a que el proveedor cierre el RCA; el responsable del tratamiento mantiene su propio plazo de 72 horas del RGPD art. 33. Dejad constancia de quién decide, cuándo se revisa el impacto y qué evidencias del proveedor sustentan cada actualización.
La práctica que mejor funciona es enviar un holding statement con hechos confirmados, impacto potencial, medidas adoptadas y hora del siguiente update, evitando atribuir causa o alcance hasta validar evidencias. En paralelo, documentaría la clasificación DORA y la evaluación RGPD por separado, incluyendo la decisión de notificar o no a la AEPD y la base objetiva de cada actualización.
En la práctica, añadiría un punto que suele olvidarse: activar ya el derecho de auditoría y conservación de evidencias previsto en el contrato con el SaaS, incluyendo logs, IOCs y cadena de custodia, no solo pedir el RCA. El holding al cliente debe indicar expresamente que el alcance está en investigación y fijar una hora concreta para la próxima actualización, aunque no haya novedades.
Suscribo lo anterior y añadiría involucrar ya al DPO y al responsable contractual: el holding al cliente debe dejar claro si actuamos como responsable o encargado, evitando afirmar “no afectados” sin evidencia suficiente. En paralelo, preservad logs y evidencias con el proveedor y registrad cada actualización, decisión de notificar y hito comprometido; esa trazabilidad será clave tanto para DORA como para el RGPD.
Como cierre operativo, fijaría un umbral de escalado independiente del RCA: si no hay confirmación del proveedor dentro de la ventana acordada, comunicaría la incertidumbre y las medidas de contención, y elevaría la evaluación al DPO y al comité de crisis. En DORA, documentad también la notificación al órgano supervisor conforme al art. 19 y la clasificación del incidente, sin confundirla con la comunicación RGPD de 72 horas.
Inicia sesión para responder y votar.