Cien días entre la intrusión y la decisión

El 30 de julio de 2026 empezaron a llegar las cartas. Decían que el nombre, la dirección, la fecha de nacimiento, el número de la seguridad social, el permiso de conducir, los documentos oficiales de identidad, los datos bancarios, los números de tarjeta y los historiales médicos podían haber sido sustraídos. Para algunas de esas personas los datos robados de la tarjeta incluían el código de seguridad impreso al dorso. Quien enviaba las cartas era CareCloud, una empresa de software sanitario cuyos sistemas custodian historiales por cuenta de consultas médicas.

La intrusión fue en marzo. Los atacantes estuvieron dentro de uno de los seis entornos de historiales clínicos electrónicos de CareCloud, alojados en Amazon Web Services, entre el 10 y el 16 de marzo de 2026. El entorno quedó afectado el 16 de marzo y se restableció esa misma tarde. La empresa hizo público el incidente a finales de mes, señalando a la vez que la investigación sobre lo que realmente se había consultado seguía en curso.

Esa investigación llegó a su conclusión el 24 de junio, cuando CareCloud determinó que había información personal, financiera y médica comprometida. Del 16 de marzo al 24 de junio hay exactamente cien días. Hasta las primeras cartas hay ciento treinta y seis.

El plazo no empieza donde usted supone

La notificación de brechas sanitarias en Estados Unidos se rige por una regla de sesenta días: avisar a los afectados sin demora injustificada y a más tardar sesenta días naturales después del descubrimiento de la brecha. Leído sin más, descubrimiento suena al día en que uno se entera de que ha sido asaltado, que aquí fue el 16 de marzo. Con esa lectura, las cartas llegan más de dos meses tarde.

La lectura que hace cuadrar este calendario es otra. Entiende por descubrimiento el día en que la investigación concluye que había información protegida realmente afectada, es decir el 24 de junio. Contando sesenta días desde ahí, unas cartas del 30 de julio caen holgadamente dentro del plazo. Esa es la lectura en la que se apoya ampliamente la práctica, y por eso este calendario se puede defender en todos los estados donde CareCloud presentó aviso, entre ellos California, Massachusetts, Nuevo Hampshire, Texas y Maine.

Sea cual sea la lectura correcta, fíjese en lo que hace la segunda. Convierte el inicio del plazo en un resultado de la investigación, y ninguna norma pone fecha límite a terminar una investigación. Un deber que empieza cuando usted decide que empieza es un deber cuyo calendario controla usted.

Europa escribió la regla al revés

El artículo 33 del RGPD obliga al responsable a notificar a la autoridad de control una violación de la seguridad de los datos personales sin dilación indebida y, de ser posible, dentro de las 72 horas siguientes a tener conocimiento de ella. Tener conocimiento no es haber cerrado un informe forense. Es el punto en que existe un grado razonable de certeza de que un incidente de seguridad ha comprometido datos personales, y ese punto llega casi siempre mucho antes de saber de quién eran los datos y cuántos.

El legislador previó exactamente el hueco en el que CareCloud pasó cien días. El artículo 33.4 dice que cuando la información no esté disponible de una sola vez podrá facilitarse de manera gradual sin más dilación indebida. El supuesto de diseño es que usted notifique todavía a ciegas y complete a medida que aprende. El modelo americano le deja esperar hasta saber; el europeo le obliga a informar antes de saber y a seguir informando.

La consecuencia para un operador no es abstracta. El mismo incidente, sobre la misma infraestructura, produce una notificación en 72 horas a un lado del Atlántico y una determinación en cien días al otro. Si los reflejos de su proveedor se formaron con el segundo calendario, son esos reflejos los que ahora se interponen entre usted y su propio plazo.

El cuadro creció mientras el plazo se aplazaba

Aplazar el inicio del plazo sería menos grave si la versión inicial se hubiera sostenido. No se sostuvo. La propia descripción de CareCloud en marzo cifraba el acceso no autorizado en unas ocho horas del 16 de marzo, contenido en un único entorno y sin implicar otros sistemas del negocio. Las presentaciones estatales posteriores describen atacantes dentro de ese entorno del 10 al 16 de marzo, es decir seis días en lugar de ocho horas.

La población afectada también creció. Las presentaciones sitúan la cifra en al menos 345.000 personas, después se ha informado de más de 350.000, y se esperan nuevas comunicaciones estatales que vuelvan a moverla. La empresa ha declarado que un atacante afirmó haber extraído datos de sus bases, que especialistas externos aseguraron el entorno y confirmaron que no quedaba acceso no autorizado persistente, y que no tiene indicios de que los datos robados se hayan utilizado indebidamente. Su consejero delegado, Stephen Snyder, declinó hacer comentarios cuando le consultaron los periodistas.

Todas esas revisiones fueron en la misma dirección y todas llegaron después de la primera versión pública. Una investigación que todavía está ampliando su propia estimación no es una razón para hacer esperar a los afectados. Es la razón para avisarles pronto y corregir al alza en público.

La cifra que falta va en su contrato

Si un proveedor trata datos personales por cuenta suya, usted es el responsable y las 72 horas son suyas. El artículo 33.2 obliga al encargado a notificar al responsable sin dilación indebida, y no adjunta cifra alguna a esa expresión. El artículo 28 exige que su contrato vincule al encargado a asistirle en sus obligaciones del artículo 33. Entre esas dos disposiciones hay un hueco con forma de número, y si usted no lo rellena hereda el calendario que tolere el regulador de su proveedor.

Rellénelo con dos cláusulas y no con una. La primera fija un plazo cerrado, contado en horas, desde el momento en que el proveedor detecta un incidente de seguridad en un entorno que contiene datos suyos, y no desde el momento en que establece qué datos estaban implicados, porque ese segundo suceso es el que no tiene fecha límite. La segunda le da derecho a los hechos según vayan apareciendo, incluidos los entornos afectados, la ventana de acceso y las categorías en riesgo, en lugar de a un único informe cerrado al final.

Después póngalo a prueba como pondría a prueba una copia de seguridad. Pregunte por escrito a sus tres mayores encargados cuándo tuvieron el último incidente de seguridad en un entorno con datos suyos, en qué fecha lo detectaron y en qué fecha avisaron a un cliente. Un proveedor que no sepa separarle esas dos fechas cuando se le pregunta tampoco las separará bajo presión. En España la notificación se presenta ante la Agencia Española de Protección de Datos, y esa autoridad le preguntará a usted, no a su proveedor, por qué llegó tarde.