El adjunto en el que nadie se detuvo a pensar

El documento que se filtró lo adjuntó alguien que estaba haciendo bien su trabajo. Una asociada del área fiscal choca con un error de permisos en la declaración de un cliente, abre un ticket al equipo interno de TI y adjunta el archivo para que el analista pueda reproducir el fallo. El ticket se cierra esa misma tarde. Del adjunto ya nadie vuelve a hablar.

Ernst & Young ha revelado que un tercero no autorizado accedió a una plataforma externa de gestión de servicios de TI que sus equipos internos utilizan para dar soporte a la práctica fiscal. En palabras de la propia EY, los tickets de soporte enviados a través de la plataforma "pueden incluir documentos que contengan información fiscal de clientes". Los tipos de datos comunicados incluyen datos personales y financieros contenidos en declaraciones fiscales o usados para prepararlas.

EY afirma que el intruso estuvo en la plataforma entre el 28 de marzo de 2026 y el 12 de abril de 2026 y descargó documentos relativos a varios clientes de EY. La firma también declara que no tiene constancia de ningún uso indebido ni de mayor exposición de la información personal afectada. Ambas afirmaciones constan. Solo la segunda tranquiliza.

Dos semanas dentro, once días hasta detectarlo, tres meses hasta avisar

Aquí pesan más las fechas que la técnica. El acceso va del 28 de marzo de 2026 al 12 de abril de 2026. EY detectó actividad anómala el 23 de abril de 2026. Las cartas de notificación a los clientes afectados están fechadas el 13 de julio de 2026 y el 15 de julio de 2026 se presentó una comunicación ante el Fiscal General de California. Se notificó a cuatro estados.

Lo que EY no ha publicado importa igual. No se ha nombrado al proveedor de la plataforma. No se ha revelado el vector de acceso inicial. No hay cifra de afectados y sigue sin estar claro cuántos clientes lo están. Ningún grupo de ransomware ha reivindicado el ataque, lo que elimina la fuente pública habitual para inventariar los archivos robados.

Para un cliente de la firma, esa combinación es lo difícil. Usted sabe que sus documentos pueden haberse movido. No sabe cuáles, no conoce la vía de entrada y no puede verificarlo de forma independiente porque los registros nunca estuvieron en su poder. Todo lo que puede decir a una autoridad es una cita ajena.

El servicio de soporte es un almacén de datos que nadie cartografió

El sistema que se filtró no era la plataforma fiscal. Era la cola de tickets. Esa distinción es la lección entera y se aplica a despachos mucho más pequeños que EY.

El personal adjunta documentos de clientes a los tickets de soporte por rutina, porque adjuntar el archivo es la vía más rápida para que se resuelva el fallo. En pocos años, el soporte acumula en silencio una copia en la sombra, sin clasificar, alojada en el proveedor y conservada de forma indefinida, del material más sensible que guarda la firma. Nadie lo diseñó. Es un subproducto de que todo el mundo quiera ayudar.

Además suele ser invisible sobre el papel. La plataforma ITSM rara vez aparece en un mapa de datos, rara vez figura en el registro de actividades de tratamiento y rara vez activa una evaluación de impacto, porque nadie clasifica el soporte de TI como un lugar donde residen datos de clientes. La plataforma fiscal recibe la revisión de cifrado, la recertificación de accesos y una política de conservación. La cola que guarda copias de los mismos documentos recibe una renovación de licencia.

Su plazo de 72 horas empieza cuando lo decide su encargado

El retraso de un encargado del tratamiento se resta directamente de su propia ventana de cumplimiento. Según el RGPD, el deber de notificar en 72 horas corre desde el momento en que el responsable tiene conocimiento de la violación de datos. Si quien custodia sus datos tarda casi tres meses en avisarle, su plazo empieza casi tres meses después de que el atacante terminara.

Aplíquelo a estas fechas. Detección el 23 de abril de 2026, cartas a clientes del 13 de julio de 2026. Un despacho que recibe esa carta abre a mediados de julio su conversación con la AEPD sobre descargas ocurridas a finales de marzo, sin telemetría propia, sin proveedor identificado y sin un alcance de exposición que describir.

Las autoridades no son indiferentes a quién causó el retraso, y un responsable que actuó con diligencia con la información disponible está en posición defendible. Aun así, la experiencia práctica sigue siendo mala: usted explica una brecha temporal que no creó, con hechos que no puede verificar, ante una autoridad que preguntará con razón por qué su contrato permitía ese retraso.

Tres cambios que compensan antes del próximo ciclo de auditoría

Empiece por averiguar qué contiene de verdad su cola de tickets. Exporte un año de adjuntos por tipo de archivo y tome muestras. La mayoría de las firmas que hacen este ejercicio encuentran nóminas, documentos de identidad, contratos firmados y papeles de trabajo fiscales dentro de tickets cerrados y olvidados hace años.

Después fije la conservación. Los adjuntos de tickets resueltos deben caducar según un calendario definido y borrarse de forma automática, y el valor por defecto debe medirse en semanas. Cuando reproducir un fallo exija datos de clientes de verdad, el flujo debe dirigir al personal a una ubicación controlada en lugar del cuerpo del ticket, y la plataforma debe poder demostrar esa diferencia.

Por último, lea el contrato del proveedor contra este escenario concreto. Compruebe que el alcance de los datos protegidos cubre cuerpos de ticket y adjuntos, y no solo los registros centrales del proveedor. Compruebe que la obligación de notificación se expresa en horas desde el conocimiento del proveedor. Compruebe que tiene derecho al detalle forense, incluido el vector de acceso, que necesitará para responder ante su propia autoridad.

Leer a continuación: 570 parches de Windows en un día, dos ya explotados  |  Rote todos los secretos que Grok Build haya visto alguna vez