Una guía práctica de Cuando las plataformas de analítica violan tus datos

Nadie trata una filtración de analítica con la urgencia de una de tarjetas, y es un error: cuando las plataformas de analítica violan tus datos salen URLs, términos de búsqueda, referencias e identificadores.

Las filtraciones de datos de analítica rara vez se tratan con la urgencia de las filtraciones de tarjetas de pago o el robo de credenciales. Eso es un error. Las plataformas de analítica pueden contener URLs, términos de búsqueda, referencias, ID de campaña, ubicación derivada de IP, eventos de cuenta, uso de productos y, a veces, identificadores a nivel de usuario. En el contexto equivocado, esos datos pueden revelar clientes, estrategias, intereses de salud, embudos de adquisición o comportamiento confidencial de los productos.

La cuestión legal también está clara: según GDPR, una violación de datos personales incluye la destrucción, pérdida, alteración, divulgación no autorizada o acceso no autorizado a datos personales. El responsable del tratamiento debe evaluar el riesgo y es posible que deba notificar a la autoridad supervisora ​​en un plazo de 72 horas según el artículo 33 y a las personas afectadas según el artículo 34. El hecho de que un proveedor haya causado el incidente no elimina la responsabilidad del responsable del tratamiento.

Cómo se ven las infracciones de análisis

No todos los incidentes se deben a que un hacker extrae una base de datos. Muchos incidentes de análisis provienen de fallas operativas ordinarias:

• Un panel multiinquilino muestra los datos de un cliente a otro cliente.
• El registro de depuración almacena URLs completo que contiene correos electrónicos, tokens de reinicio o parámetros de consulta de estado.
• Una exportación de BigQuery, S3 o almacén de datos mal configurada se vuelve pública.
• El personal de soporte puede acceder a transmisiones de eventos sin formato sin ningún motivo comercial.
• Un administrador de etiquetas carga un script no aprobado que copia los datos del evento a un tercero.
• Un proveedor subprocesa datos en un país que no estaba cubierto por el contrato o la evaluación de la transferencia.

Estos incidentes son dolorosos porque los datos de analítica suelen ser amplios. Un script de seguimiento puede afectar a cada página y a cada recorrido del usuario.

La soberanía de los datos es más que la ubicación del servidor

La soberanía de los datos significa que usted comprende qué leyes, empresas, personas e infraestructura pueden afectar tus datos. Alojar en Frankfurt o Dublín es útil, pero no responde a todas las preguntas. Aún necesita conocer la jurisdicción corporativa del proveedor, los subprocesadores, el acceso al soporte remoto, el modelo de cifrado, el proceso de respuesta a incidentes y si los datos se pueden transferir fuera del EEE.

Para los datos personales de la UE, las transferencias internacionales se rigen por el GDPR Capítulo V. Las transferencias pueden depender de una decisión de adecuación, cláusulas contractuales estándar, reglas corporativas vinculantes u otro mecanismo aprobado. Después de que el Tribunal de Justicia invalidara el Escudo de Privacidad en Schrems II, las organizaciones también tuvieron que considerar si eran necesarias medidas complementarias para las transferencias a países con riesgos de vigilancia. El Marco de Privacidad de Datos UE-EE.UU. ya existe, pero se aplica solo a organizaciones estadounidenses certificadas y sigue siendo un área de riesgo que debe ser monitoreada.

Por qué la infraestructura compartida cambia el modelo de riesgo

La mayoría de las plataformas de analítica SaaS son multiinquilino. Eso es normal, pero hace que el aislamiento de los inquilinos sea un control crítico. Quiere evidencia de que los datos del cliente están separados en las capas de aplicación, base de datos, control de acceso, registro, respaldo y soporte.

Solicite a los proveedores respuestas precisas:

• ¿Los inquilinos están separados por base de datos, esquema, permisos a nivel de fila o lógica de aplicación?
• ¿Puede el personal consultar directamente los eventos sin procesar de los clientes?
• ¿Se registran y revisan las sesiones de acceso a producción?
• ¿Están cifradas las exportaciones en reposo y en tránsito?
• ¿Cómo se aíslan y eliminan las copias de seguridad?
• ¿Qué sucede si la configuración de un inquilino se aplica accidentalmente a otro?

Si un proveedor no puede explicar claramente la separación de inquilinos, se trata de un riesgo de adquisición, no de una peculiaridad de la documentación.

Preparación para incidentes para datos de analítica

Un plan de incidentes analítico práctico debe definir qué se considera reportable, quién realiza la llamada y con qué rapidez se pueden recopilar pruebas. Incluya análisis en sus ejercicios de mesa sobre violaciones. La investigación debe responder:

1. ¿Qué conjuntos de datos quedaron expuestos o alterados?
2. ¿Los datos incluían datos personales, identificadores seudónimos o datos sensibles URLs?
3. ¿Cuántas personas y cuentas se vieron afectadas?
4. ¿Podrían los datos estar vinculados a personas físicas?
5. ¿Otro cliente, un empleado del proveedor, el público o un atacante accedió a los datos?
6. ¿Se requieren notificaciones al regulador o al cliente?
7. ¿Qué registros prueban la contención?

Las directrices de notificación de infracciones del CEPD son útiles porque se centran en el riesgo, no en las etiquetas.

Cómo reducir la exposición antes de un incidente

El control más fuerte es la minimización. No envíe datos personales a análisis a menos que realmente los necesite. Evita recopilar URLs completo si URLs puede contener información del usuario. Elimina los parámetros de consulta de forma predeterminada y permite solo los parámetros de campaña aprobados. Nunca coloque correos electrónicos, números de teléfono, nombres, tokens o valores de formularios de texto libre en las propiedades del evento.

A continuación, acorte la retención. Conserve los datos de eventos sin procesar solo mientras sean útiles desde el punto de vista operativo y luego agréguelos. Una ventana de eventos sin procesar de 30 o 90 días puede ser suficiente para la depuración y el análisis del embudo, mientras que los informes agregados mensuales se pueden conservar por más tiempo.

Por último, prefiera arquitecturas que limiten el acceso de terceros. Para algunos equipos, eso significa un SaaS alojado en la UE que prioriza la privacidad, con contratos sólidos y sin identificadores entre sitios. Para los equipos regulados o del sector público, puede significar infraestructura autohospedada o dedicada, claves de cifrado administradas por el cliente y aprobaciones estrictas de acceso al soporte.

Preguntas de debida diligencia del proveedor

Antes de elegir una plataforma de análisis, pregunte por:

• Un acuerdo de tratamiento de datos y una lista de subprocesadores.
• Residencia de datos y documentación de transferencia.
• Certificaciones de seguridad o auditorías independientes cuando estén disponibles.
• Un compromiso de notificación de incumplimientos con plazos.
• Una política de retención y eliminación.
• Una lista de campos e identificadores recopilados.
• Soporte para deshabilitar cookies, almacenamiento de IP, huellas digitales y seguimiento a nivel de usuario.
• Exportar y eliminar flujos de trabajo si te vas.

Se supone que la analítica reduce la incertidumbre. Si la plataforma en sí crea incertidumbre legal, de seguridad y de soberanía, la herramienta está actuando en contra del negocio.

Lista de verificación de análisis listos para incidentes

Prepárese para incidentes analíticos antes de que sucedan. Mantén un mapa de datos actualizado, una lista de proveedores, una lista de subprocesadores, un cronograma de retención, un registro de acceso, una ruta de exportación y una ruta de contacto para recibir avisos de seguridad. Incluya herramientas de analítica en los ejercicios teóricos de incumplimiento.

Reduzca el radio de explosión recopilando menos identificadores, excluyendo URLs y eventos sensibles, acortando la retención de datos sin procesar, limitando el acceso al panel y prefiriendo proveedores que puedan explicar la separación de inquilinos, el acceso al soporte y la ubicación de los datos en términos concretos.

Preguntas frecuentes

¿Con qué rapidez hay que notificar una filtración de datos de analítica según el RGPD?

Según el RGPD, los responsables deben notificar a la autoridad de control en un plazo de 72 horas desde que tienen conocimiento de una violación de datos personales conforme al artículo 33. El artículo 34 regula cuándo hay que informar directamente a las personas afectadas. Que el incidente lo haya causado un proveedor no elimina la responsabilidad propia del responsable del tratamiento. El plazo empieza cuando hay información suficiente para evaluar el riesgo, no cuando termina la investigación.

¿Un error del proveedor sigue contando como infracción según el RGPD?

Sí. El RGPD define una violación de datos personales como cualquier destrucción, pérdida, alteración, divulgación o acceso no autorizados a datos personales, sea accidental o ilícito, sin importar quién lo cause. Que una mala configuración del proveedor desencadene el incidente no elimina las obligaciones de notificación propias del responsable.

¿Qué se considera dato personal dentro de una plataforma de analítica?

Las herramientas de analítica pueden capturar URLs, términos de búsqueda, referentes, IDs de campaña, ubicación derivada de la IP, eventos de cuenta, uso del producto y a veces identificadores a nivel de usuario. Cualquiera de ellos puede convertirse en dato personal en cuanto se vincula a una persona, por ejemplo un token de restablecimiento incluido en una URL guardada en un registro de depuración. Por eso el artículo trata las plataformas de analítica con la misma seriedad que los sistemas de tarjetas de pago.

¿Cuál es la diferencia entre alojar datos en la UE y tener verdadera soberanía de datos?

La ubicación del servidor es solo una parte. La soberanía de los datos también depende de la jurisdicción corporativa del proveedor, sus subencargados, el acceso remoto de soporte, el modelo de cifrado, el proceso de respuesta a incidentes y si los datos pueden salir del EEE. Un panel alojado en Fráncfort puede seguir siendo accesible para personal o subencargados fuera de la UE.

¿Por qué importó Schrems II para los proveedores de analítica?

El Tribunal de Justicia de la Unión Europea invalidó el Privacy Shield entre la UE y Estados Unidos en la sentencia Schrems II. Esa sentencia obligó a las organizaciones a reevaluar si hacían falta medidas adicionales para las transferencias a países con riesgo de vigilancia. El EU-US Data Privacy Framework existe ahora, pero solo cubre a organizaciones estadounidenses certificadas y sigue siendo un área de riesgo que conviene vigilar.

¿Qué se debe preguntar a un proveedor sobre el aislamiento de inquilinos?

Pregunte si los inquilinos están separados por base de datos, esquema, permisos a nivel de fila o lógica de aplicación, si el personal puede consultar directamente los eventos en bruto de los clientes, y si las sesiones de acceso a producción quedan registradas y revisadas. Pregunte también cómo se cifran y aíslan las exportaciones y las copias de seguridad, y qué ocurre si la configuración de un inquilino se aplica por error a otro. Un proveedor que no puede responder con claridad es un riesgo de contratación, no un simple trámite.

¿Cuánto tiempo hay que conservar los datos de eventos en bruto?

Solo mientras sigan siendo operativamente útiles, y después pasar a agregados. Una ventana de 30 o 90 días de datos en bruto suele bastar para depuración y análisis de embudo, mientras que los informes agregados mensuales pueden conservarse más tiempo sin la misma exposición.

¿Cuáles son ejemplos de errores comunes que provocan infracciones de analítica?

Las causas habituales incluyen un panel multiinquilino que muestra los datos de un cliente a otro y registros de depuración que guardan URLs completas con correos o tokens de restablecimiento. A eso se suman una exportación de BigQuery o S3 mal configurada que queda pública, personal de soporte que accede a flujos de eventos en bruto sin motivo de negocio y un gestor de etiquetas que carga un script no aprobado que copia datos a un tercero. Ninguno de estos casos necesita un atacante. Son fallos operativos.

¿Qué debe responder una investigación de un incidente de analítica?

La investigación debe identificar qué conjuntos de datos quedaron expuestos o alterados, si los datos incluían datos personales, identificadores seudónimos o URLs sensibles, y cuántas personas y cuentas se vieron afectadas. También debe resolver si los datos pueden vincularse a personas, quién accedió a ellos, y si hace falta notificar al regulador o a los clientes, con registros que demuestren la contención.

¿Qué se debe pedir durante la debida diligencia de un proveedor?

Solicite un contrato de encargo de tratamiento y la lista de subencargados, documentación de residencia y transferencia de datos, y certificaciones de seguridad o auditorías independientes cuando existan. Pida también un compromiso de notificación de incidentes con plazos, una política de retención y borrado, una lista de los campos e identificadores recopilados, y flujos de exportación y borrado para cuando decida dejar el proveedor.