Esto no es asesoramiento legal. Es la checklist práctica que construimos para nosotros mismos trabajando con clientes en Alemania, Italia y el Reino Unido, y que repetimos en cada proyecto nuevo. No sustituye a su abogado, pero acorta mucho la reunión con él.
El marco básico: su cliente es el responsable del tratamiento, usted es casi con toda seguridad el encargado, y cada servicio en la nube que utiliza es un subencargado. Una vez que esos tres términos están bien colocados, el resto de la lista se ordena por sí solo.
El RGPD no es papeleo; es una decisión de arquitectura. Los documentos describen la arquitectura — no la sustituyen.
01La capa contractual: un DPA y cláusulas contractuales tipo
Necesita un acuerdo de tratamiento de datos (DPA) firmado con cada cliente de la UE. Como Türkiye no cuenta con una decisión de adecuación, si los datos se procesan en Türkiye ese DPA va acompañado de cláusulas contractuales tipo y una breve evaluación de impacto de la transferencia. En la práctica, estos tres documentos viajan juntos, y una vez bien preparados se reutilizan en cada proyecto.
El segundo paso es la lista de subencargados. Cada servicio que utiliza — alojamiento, correo transaccional, seguimiento de errores, analítica, copias de seguridad — figura en ella con su nombre, finalidad y región, y esa lista se comparte con el cliente. Añadir una línea es un hecho notificable según el contrato, por lo que mantenerla como una página y enlazarla es el enfoque más práctico.
02La capa de arquitectura: región, conservación, eliminación
Para clientes de la UE, nuestra opción por defecto es inequívoca: base de datos y almacenamiento de objetos en una región de la UE (Viena o Irlanda), con las copias de seguridad permaneciendo en la misma región. Esa única decisión simplifica las respuestas a las cien preguntas que siguen. Si el equipo de desarrollo accede desde Türkiye, se trata de acceso remoto, y así se describe en el DPA.
Los periodos de conservación se definen por tipo de dato: registros de contrato y factura durante los años que exige la ley, consentimientos de marketing hasta su retirada, registros de acceso al servidor noventa días, currículums de candidatos seis meses. Codificar esos plazos en el software — un campo de fecha de eliminación y una tarea nocturna — es más fiable que escribirlos en un documento.
Trate las solicitudes de eliminación y exportación como una funcionalidad desde el primer día. Si puede exportar y borrar los datos de un usuario en una sola operación, el plazo legal de treinta días deja de ser una fuente de estrés. Añadirlo más tarde siempre es difícil, porque para entonces los datos ya se han repartido entre cinco tablas.
03Práctica diaria: cookies, formularios, plan ante brechas
El banner de cookies no es un elemento de diseño sino una promesa técnica: los scripts de analítica y marketing no deben cargarse antes del consentimiento, y «rechazar» debe ser tan visible como «aceptar». Un sitio que acierta en esos dos puntos ya ha superado los dos primeros elementos de cualquier auditoría.
En los formularios, separe las finalidades: una consulta de proyecto y una suscripción a un boletín son dos consentimientos distintos, y ninguna casilla llega premarcada. Cada formulario enlaza a un aviso de privacidad, y ese aviso describe realmente los campos de ese formulario.
El último punto es el que nadie quiere preparar: el plan ante brechas. Una página que indique a quién se notifica, dónde se leen los registros, qué se le escribe al cliente, y quién es responsable del plazo de setenta y dos horas. Escribir esa página en un día tranquilo es mucho más barato que escribirla en uno malo.
Escrito por
El equipo de Paradigma7
Producto, ingeniería y operaciones
Somos un equipo con sede en Ankara que construye software para Europa. Nada aquí es teoría: estos son los procesos que realmente ejecutamos en proyectos de clientes.
Sobre nosotros