Checklist de base jurídica del tratamiento para founders y responsables de compliance

Las decisiones sobre base jurídica parecen sencillas hasta que producto quiere lanzar rápido, un cliente pide explicaciones o una auditoría exige entender por qué un uso de datos era válido. En ese momento se ve que no basta con una etiqueta legal. Hace falta un modo repetible de demostrar propósito, necesidad, owners y evidencia.

Por eso esta checklist es útil. El GDPR exige una base jurídica para tratar datos personales y la guía oficial del EDPB y de la ICO insiste en elegirla antes de empezar, ajustarla al fin real y poder justificarla después. Para equipos lean, el objetivo es práctico: decidir pronto, documentar bien y evitar reconstrucciones de última hora.

Qué intenta evitar esta checklist

La mayoría de los problemas no vienen de ignorar privacidad, sino de estos vacíos:

• el fin es demasiado vago;
• una misma base se estira para actividades distintas;
• el flujo cambia y nadie revisa la decisión;
• alguien conoce la etiqueta, pero nadie puede explicar el porqué.

Esto termina generando fricción en revisiones de clientes, procurement, onboarding de vendors, lanzamientos y auditorías internas.

La checklist

Úsala para cualquier tratamiento material: nuevas funcionalidades, analítica, marketing, integraciones, cambios de retención o compartición de datos.

1. Define el tratamiento de forma concreta

Evita frases como "tratamos datos de clientes para operar la plataforma". Describe el flujo real:

• crear y autenticar cuentas;
• enviar facturas y recordatorios de pago;
• gestionar tickets de soporte;
• medir uso del producto;
• detectar accesos sospechosos;
• enviar campañas promocionales.

Cuanto más concreto sea el flujo, más fácil será evaluar si la base encaja.

2. Escribe el fin específico

La base jurídica debe corresponder al fin del tratamiento. Pregunta:

• qué resultado busca ese tratamiento;
• si el fin es comercial, operativo, legal, de seguridad o de producto;
• si el mismo dato se reutiliza para un fin adicional que requiere análisis separado.

3. Prueba la necesidad antes de elegir la base

Para contrato, verifica si el servicio puede prestarse sin esos datos. Para obligación legal, identifica la norma concreta que impone el tratamiento. Para interés legítimo, aclara cuál es el interés, por qué el tratamiento es necesario y qué esperarían razonablemente las personas. Para consentimiento, confirma que existe elección real y retirada sencilla.

4. Revisa si hay datos sensibles o categorías especiales

Una base del artículo 6 no basta si el flujo incluye datos de salud, biométricos para identificación, opiniones políticas, creencias religiosas u otras categorías especiales. En esos casos también hay que revisar las condiciones adicionales del artículo 9.

5. Deja la justificación en un registro corto

No hace falta un memo largo. Sí hace falta un registro breve con:

• actividad de tratamiento;
• fin;
• base jurídica elegida;
• por qué encaja;
• sistemas o vendors implicados;
• owner de la decisión;
• condiciones y salvaguardas;
• disparadores de re-review.

6. Comprueba que el flujo real coincide con la decisión

El registro sirve de poco si la operativa hace otra cosa.

Revisa, por ejemplo:

• si el consentimiento puede rechazarse y retirarse con facilidad;
• si bajo contrato solo se recogen los datos realmente necesarios;
• si las obligaciones legales están bien mapeadas a retención o disclosure;
• si siguen siendo válidas las salvaguardas del interés legítimo.

7. Alinea notices, formularios y mensajes externos

La explicación interna y la externa no deberían divergir. Privacy notice, formularios, pantallas de producto y claims comerciales deben reflejar el mismo fin y los mismos límites.

8. Asigna owner de mantenimiento, no solo de aprobación

Cada decisión relevante debería tener:

• un owner de la lógica de decisión;
• un owner de que el flujo siga cumpliendo esa lógica.

9. Define disparadores claros para revisar de nuevo

Revisa otra vez cuando:

• cambie el fin;
• entre un nuevo vendor o subencargado;
• aumente el dataset;
• cambien mercados o segmentos;
• aparezcan datos sensibles;
• cambien de forma material las reglas de retención o sharing.

10. Conserva evidencia ligera y localizable

La evidencia útil suele ser:

• un inventario de tratamientos con fin y base significativos;
• registros cortos de decisión para flujos de mayor riesgo;
• formularios o tickets con las preguntas correctas;
• capturas o logs sobre consentimiento, disclosure, retención o controles.

Un despliegue simple en 30 días

Semana 1: elige los flujos más importantes

Empieza por cinco o diez tratamientos que ya generan presión, como signup, billing, soporte, analítica, seguridad o marketing.

Semana 2: documenta fin y base

Crea un pequeño registro por flujo.

Semana 3: compara documentación y realidad

Revisa si formularios, notices, producto, vendors y retención coinciden con la decisión documentada.

Semana 4: fija owners y triggers

Asigna responsables, decide dónde vive el registro y establece los triggers de nueva revisión.

Errores frecuentes

Usar contrato como respuesta general

Puede servir para la entrega del servicio, pero no para cualquier fin adyacente.

Tratar consentimiento como la opción más segura

No lo es si no hay libertad real o retirada fácil.

Esconder varios fines en una sola respuesta

Un nuevo fin suele requerir un nuevo análisis.

Documentar la base pero no su límite

El equipo debe saber en qué condiciones esa base sigue siendo defendible.

Guardar la decisión en un documento que nadie usa

Si producto, procurement o seguridad no pueden aplicarla en el trabajo diario, todavía no está operativizada.