Diagrama de mapeo de datos RGPD: cómo mapear los flujos de datos personales entre tus sistemas

Pregunta a un equipo de privacidad dónde están los datos personales y te dará una hoja de cálculo. Pregunta a ingeniería y te dará un diagrama de arquitectura que nunca menciona datos personales. Los dos están incompletos: la hoja de cálculo no puede mostrar cómo se mueven los datos, y el diagrama de arquitectura no dice qué se mueve ni por qué.

Un diagrama de mapeo de datos RGPD es el punto donde los dos se encuentran. Esta guía cubre lo que debe recoger un mapa de datos, un método para construirlo y un mapa resuelto para un producto SaaS típico. No es asesoramiento jurídico: las bases jurídicas, los mecanismos de transferencia y los plazos de conservación los decide quien lidere la privacidad en tu empresa o tu asesoría legal.

Mapa de datos y registro de actividades de tratamiento

El artículo 30 del RGPD obliga a cada responsable del tratamiento a llevar un registro de las actividades de tratamiento que contenga:

• el nombre y los datos de contacto del responsable y, en su caso, de su representante y del delegado de protección de datos;
• los fines del tratamiento;
• las categorías de interesados y de datos personales;
• las categorías de destinatarios, incluidos los destinatarios en terceros países;
• las transferencias a terceros países y, en algunos casos, la documentación de las garantías;
• cuando sea posible, los plazos previstos para la supresión;
• cuando sea posible, una descripción general de las medidas de seguridad.

Los encargados del tratamiento llevan un registro similar del tratamiento que realizan para cada responsable. El artículo 30, apartado 5, exime a las organizaciones con menos de 250 empleados, pero solo si no es probable que el tratamiento entrañe un riesgo para los derechos de las personas, si es ocasional y si no incluye categorías especiales de datos ni datos relativos a condenas penales. Una empresa SaaS que trata datos de clientes a diario rara vez cumple esas condiciones. Los legisladores de la UE han debatido elevar ese umbral, así que comprueba el texto vigente antes de basarte en él.

El registro es una tabla. El mapa de datos es la forma de averiguar qué va en esa tabla y de comprobar después que sigue siendo cierto.

Qué recoger para cada flujo

Un método que funciona

1. Haz inventario de los sistemas. Empieza por lo que puedes listar: cuentas en la nube, bases de datos, herramientas SaaS que aparecen en el inicio de sesión único (SSO) y en los pagos a proveedores del equipo de finanzas. Ahí salen a la luz las herramientas en la sombra.
2. Sigue un recorrido de usuario cada vez. Registro, facturación, uso diario del producto, un ticket de soporte, un correo de marketing. Dibuja dónde entran los datos, dónde se almacenan y adónde van después.
3. Pregunta a los propietarios. Para cada sistema: qué campos, para qué, quién los recibe y cuánto tiempo se quedan.
4. Marca encargados y transferencias. Anota dónde trata los datos cada proveedor, si hay un contrato de encargo del tratamiento firmado y qué garantía cubre cualquier transferencia fuera del EEE.
5. Añade la conservación y la supresión. Un almacén sin plazo de conservación ya es un hallazgo.
6. Revisa el mapa con el equipo de privacidad y deriva de él el registro del artículo 30.

Transferencias fuera del EEE

El capítulo V del RGPD, artículos 44 a 49, solo permite transferencias a terceros países sobre determinadas bases. Las habituales para una empresa SaaS:

• Una decisión de adecuación. La Comisión Europea publica la lista de países cuya protección considera adecuada. Para Estados Unidos, la decisión de julio de 2023 cubre a las empresas que participan en el Marco de Privacidad de Datos UE-EE. UU. (DPF). El Tribunal General de la UE la confirmó en septiembre de 2025 y en octubre de 2025 se interpuso un recurso ante el Tribunal de Justicia, así que comprueba su situación antes de basarte en ella.
• Cláusulas contractuales tipo. Las cláusulas contractuales tipo (SCC) que la Comisión adoptó en 2021 son la garantía contractual habitual cuando no se aplica ninguna decisión de adecuación.
• Otras garantías y excepciones, como las normas corporativas vinculantes o el consentimiento explícito, para casos más acotados.

En el mapa, una transferencia es un enlace que sale de tu región, etiquetado con el destino y la garantía.

El ejemplo resuelto: un producto SaaS B2B

El producto se ejecuta en una región de nube de la UE: una aplicación web, una base de datos PostgreSQL y un almacén de datos analítico. Cinco proveedores reciben datos personales: el envío de correo electrónico y los pagos en el EEE, y la analítica de producto, una herramienta de soporte y un CRM en Estados Unidos.

Cómo leerlo:

• Entrada. Los usuarios de los clientes crean cuentas, pagan, usan el producto y escriben a soporte. Cada flujo que sale de la aplicación web lleva una etiqueta con las categorías de datos que transporta.
• Tus sistemas, región de la UE. La base de datos de la aplicación guarda los datos de cuenta y de espacio de trabajo. El almacén recibe eventos de uso con identificadores seudonimizados, no nombres.
• Encargados en el EEE. El envío de correo recibe nombres, direcciones de correo electrónico y el contenido de los mensajes; los pagos reciben contactos de facturación y facturas. No hay ninguna transferencia.
• Encargados en EE. UU. Cada enlace que entra en este marco es una transferencia y lleva su garantía: DPF para los proveedores certificados en el marco, SCC para el que no lo está.
• La leyenda explica las etiquetas y enumera plazos de conservación de ejemplo para cada almacén.

Convenciones de dibujo que ayudan

• Etiqueta los enlaces con categorías de datos, no con tecnologías. «Nombre, correo, contenido del ticket» ayuda a quien revisa; «API REST», no.
• Dibuja una frontera alrededor de tus propios sistemas y coloca a los encargados fuera de ella, agrupados por región.
• Marca cada transferencia con el destino y la garantía.
• Destaca los datos de categorías especiales con un único color coherente, y explica en la leyenda qué significa.
• Escribe la conservación en cada almacén. Es el elemento que más a menudo falta en los registros de actividades de tratamiento.
• Mantén las finalidades y las bases jurídicas en el registro, junto al diagrama. El diagrama muestra dónde; el registro explica por qué.

Mantenlo al día

Un mapa de datos queda desfasado el día en que alguien añade un proveedor. Vincula las actualizaciones a los eventos que lo cambian: la incorporación de proveedores, las nuevas funciones que recogen datos nuevos y las evaluaciones de impacto relativas a la protección de datos. Según el artículo 35, el responsable debe evaluar, antes de empezar, cualquier tratamiento que probablemente entrañe un alto riesgo, y el mapa es el punto de partida natural de esa evaluación. Revisa el mapa completo una vez al año y conserva la versión anterior. Diagramas de arquitectura que no se quedan obsoletos describe un flujo de trabajo justo para eso, e insertar el diagrama en vivo en la wiki de privacidad mantiene a todos en la misma versión.

Cómo ayuda el mapa con las solicitudes de los interesados

Una solicitud de acceso o de supresión tiene que cubrir todos los lugares donde están los datos de una persona: la base de datos de la aplicación, el almacén, las copias de seguridad y cada encargado. Con un mapa actualizado, responder es seguir una lista de verificación en lugar de hacer una búsqueda. Los encargados están obligados por contrato a ayudar con estas solicitudes, y el mapa te dice a cuáles preguntar.

Para una visión de seguridad de los mismos flujos, consulta los diagramas de flujo de datos para el modelado de amenazas.

Constrúyelo en Archboard

1. Inicia sesión con Google o GitHub y crea un diagrama.
2. Añade una Persona del pack Modelo C4 para el usuario del cliente.
3. Añade un Marco del pack Básico para tus sistemas en la región de la UE, con un Contenedor del pack Modelo C4 para la aplicación web, un Postgres del pack Datos para la base de datos de la aplicación y un Almacén de datos del pack Datos para la analítica.
4. Añade otros dos nodos Marco del pack Básico para los encargados, uno para el EEE y otro para EE. UU., con un nodo Sistema externo del pack Modelo C4 para cada rol de proveedor.
5. Etiqueta cada enlace con las categorías de datos que transporta y añade la garantía en cada enlace que entra en el marco de EE. UU.
6. Añade un bloque Markdown del pack Básico con la leyenda y los plazos de conservación.

El ejemplo usa 13 nodos de diagrama, dentro del plan Free. El caso de uso de mapeo de datos RGPD muestra más formas de organizar un mapa.

Preguntas frecuentes

¿Exige el RGPD un mapa de datos? El RGPD exige el registro de actividades de tratamiento del artículo 30, no un diagrama. La mayoría de los equipos descubren que no pueden construir ni mantener un registro exacto sin mapear antes los flujos.

¿A quién debe pertenecer el mapa de datos? Privacidad es dueña del registro y de las decisiones que contiene; ingeniería, de los sistemas. Asigna al diagrama un dueño en cada lado y que lo revisen juntos.

¿Debe el mapa mostrar cada tabla de la base de datos? No. Muestra los almacenes y las categorías de datos que contienen. El detalle a nivel de tabla corresponde a un catálogo de datos.

¿Cómo represento a un proveedor que es a la vez encargado y responsable? Dibújalo una sola vez y etiqueta su papel en cada flujo. Algunos proveedores, como los de pagos, actúan como responsables en parte de su tratamiento; sus contratos indican en cuál.

¿Puede el diagrama sustituir al registro del artículo 30? No. El registro debe contener por escrito información concreta, incluidos los fines y las medidas de seguridad. Usa el diagrama para construir y comprobar el registro.

Empieza gratis — un puesto, sin tarjeta de crédito.