Cuándo se aplican las solicitudes de acceso de los interesados y qué hacer después

Las solicitudes de acceso se aplican en cuanto una persona quiere saber si tu organización trata sus datos personales, quiere una copia de esos datos o solicita la información complementaria que acompaña al derecho de acceso. En la práctica, la cuestión aparece antes y en más lugares de lo que muchos equipos SaaS esperan. Puede empezar en soporte, account management, ventas o privacy mucho antes de que legal haga una revisión formal.

El siguiente paso no es solo comprobar si el mensaje contiene la etiqueta legal correcta. El siguiente paso es confirmar si la persona está pidiendo realmente su información personal, qué sistemas pueden quedar dentro del scope, quién será el owner del caso y cómo se mueve la solicitud a un workflow repetible.

Para el modelo operativo completo, combina esta pieza con Solicitudes de acceso del interesado: guía práctica para equipos SaaS, Cómo operativizar las solicitudes de acceso de los interesados sin frenar la entrega de producto, Checklist de solicitudes de acceso y errores comunes en solicitudes de acceso.

Cuándo aplica el tratamiento DSAR

El derecho de acceso aplica cuando una persona quiere saber si sus datos personales están siendo tratados y, en ese caso, quiere acceso a esos datos y a la información exigida por el artículo 15. La ICO lo resume de forma muy práctica: la persona tiene derecho a confirmación, a una copia de su información personal y a información suplementaria.

Esto cubre, por ejemplo:

• usuarios que piden todos los datos asociados a su cuenta;
• antiguos prospects que preguntan qué queda en CRM o marketing;
• personas que quieren ver tickets de soporte o historial de interacción;
• empleados o contratistas que solicitan acceso a datos tratados por la empresa;
• empleados del cliente en un entorno controller-processor donde el vendor debe enrutar o apoyar la solicitud.

Cuándo aplica aunque la solicitud sea informal

Una DSAR no tiene que parecer formal para ser válida. La ICO dice que no hay requisitos formales: una persona puede hacerla verbalmente, por escrito o por redes sociales y ante cualquier parte de la organización.

Por eso muchas veces el derecho de acceso se convierte primero en un problema de frontline. Frases como estas ya pueden activar el flujo:

• "Envíame todo lo que tengáis sobre mí."
• "¿Qué datos seguís guardando de nuestra prueba?"
• "Quiero una copia de mi historial de cuenta y soporte."

El tono puede ser informal. El impacto operativo no lo es.

Cuándo no significa la misma búsqueda para todos los sistemas

Que el derecho aplique no significa que cada solicitud tenga el mismo alcance operativo. La empresa todavía tiene que decidir qué sistemas son relevantes, qué rol juega respecto a los datos afectados y qué información complementaria debe incluirse en la respuesta.

En SaaS, los datos personales suelen estar repartidos entre:

• base de datos de producto y autenticación;
• tickets de soporte, chats y adjuntos;
• billing y finanzas;
• CRM y automatización de marketing;
• analytics o telemetría cuando los datos sean personales y relevantes;
• registros mantenidos por processors.

La ICO pide una búsqueda razonable y proporcionada. Ni revisar solo lo más fácil ni buscar sin criterio.

Cuándo conviene pausar y escalar

Hay solicitudes sencillas y otras que requieren más estructura. Conviene escalar cuando:

• la identidad no está clara y hace falta una verificación proporcionada;
• el alcance es tan amplio que necesita aclaración;
• los registros pueden contener datos de terceros;
• el reparto controller-processor no está claro;
• alguien propone apoyarse en "manifestly unfounded or excessive".

En este último caso, la ICO recuerda que el umbral es alto.

Qué hacer después

1. Reconocer y registrar la solicitud

Anota canal de entrada, momento de reconocimiento y owner del caso.

2. Confirmar identidad y scope con proporcionalidad

No pidas pruebas excesivas si la identidad ya es clara, pero tampoco reveles datos sin suficiente confianza en canales inciertos.

3. Construir la búsqueda sobre sistemas relevantes

Usa un mapa de búsqueda ligado a los workflows reales.

4. Separar recopilación y revisión

Recuperar datos no es lo mismo que decidir qué puede divulgarse sin afectar a los derechos de terceros.

5. Responder con información utilizable

El artículo 15 no consiste solo en enviar archivos. La respuesta debe ayudar a entender los datos y el contexto del tratamiento.

6. Guardar evidencia del proceso

Suelen ser útiles el canal de intake, la decisión sobre identidad, los sistemas revisados, las notas de review y la fecha de respuesta.

Escenarios prácticos

Solicitud desde soporte de un usuario activo

Un usuario autenticado pide todos sus datos. El derecho aplica claramente y el siguiente paso es enrutar la solicitud al flujo DSAR y revisar los sistemas relevantes más allá de la tabla principal del producto.

Antiguo prospect pregunta qué datos quedan

Aquí el derecho también aplica si CRM, automatización de marketing, eventos o herramientas de enrichment siguen guardando información.

Empleado del cliente escribe directamente al vendor SaaS

En este caso hay que tratar la solicitud de forma estructurada y, al mismo tiempo, aclarar la asignación de roles y el canal correcto de soporte.

Idea práctica final

Las solicitudes de acceso se aplican siempre que una persona pida claramente confirmación, acceso a sus datos o la información complementaria del derecho de acceso. Lo siguiente es operativo: reconocer la solicitud, confirmar identidad y scope, buscar en los sistemas relevantes, revisar el resultado y responder de forma comprensible.