Aplicar el RGPD en el desarrollo de software significa convertir el Reglamento (UE) 2016/679 en decisiones de producto: qué campos recoges, cuánto tiempo los guardas, quién los ve y cómo se borran. Esas decisiones se toman al diseñar la base de datos y los permisos, antes de escribir código. En Codezone las incluimos en el análisis de cada proyecto como estudio de desarrollo de software en Madrid.
Corregir la privacidad con la aplicación en producción obliga a migrar tablas y rehacer permisos. Además, un acceso indebido derivado de un fallo de seguridad en aplicaciones web con OWASP se convierte en una brecha que hay que gestionar contra reloj.
Al terminar sabrás qué requisitos de privacidad meter en el backlog y qué exigir por escrito, igual que exiges la documentación técnica que entrega tu proveedor.
Qué es la privacidad desde el diseño del RGPD en el desarrollo de software
La protección de datos desde el diseño y por defecto es la obligación del artículo 25 del Reglamento (UE) 2016/679 de aplicar medidas técnicas, como la seudonimización, desde que se decide cómo se tratarán los datos. Por defecto, solo se tratan los datos necesarios para cada fin, en cantidad, extensión, plazo de conservación y accesibilidad.
El texto oficial está en EUR-Lex, Reglamento (UE) 2016/679. En la práctica, cada campo necesita una finalidad escrita, también cuando la estrategia de datos propios de clientes para marketing pide recoger más.
Requisitos del RGPD que se programan
Cuatro artículos del RGPD se traducen en funcionalidades del software:
- Minimización (art. 5.1.c): datos "adecuados, pertinentes y limitados a lo necesario". En el código, formularios sin campos de relleno y APIs que devuelven solo lo que pinta la pantalla.
- Privacidad por defecto (art. 25.2): permisos mínimos por rol y exportaciones masivas desactivadas hasta que alguien las autorice.
- Seguridad (art. 32): seudonimización y cifrado, más la capacidad de restaurar la disponibilidad rápidamente tras un incidente. El cifrado se detalla en cifrado de APIs y autenticación en apps y la restauración en la guía de RPO, RTO y pruebas de restauración.
- Registro de actividades (art. 30): recoge, cuando sea posible, los plazos de supresión de cada categoría de datos. La exención para empresas de menos de 250 personas desaparece si el tratamiento no es ocasional, lo habitual en un software de gestión.
Retención, bloqueo y borrado de datos personales
El RGPD exige conservar los datos identificables "durante no más tiempo del necesario" (art. 5.1.e), y la ley española añade un paso intermedio. El artículo 32 de la Ley Orgánica 3/2018 (LOPDGDD) publicada en el BOE obliga a bloquear los datos al suprimirlos: quedan reservados, sin visualización ni tratamiento, a disposición de jueces y autoridades durante el plazo de prescripción. Después se destruyen.
En el software eso exige un estado "bloqueado" que todas las consultas filtren y un proceso programado que seudonimice al vencer el plazo. Al cambiar de sistema, el plan de migración de datos entre programas debe excluir lo que ya tendría que estar borrado.
Derechos de los interesados implementados en el software
El responsable debe responder a las solicitudes de derechos en un mes, prorrogable dos meses más (art. 12.3 RGPD). Hacerlo desde el software deja trazabilidad:
- Acceso y portabilidad (arts. 15 y 20): exportación en "formato estructurado, de uso común y lectura mecánica", como JSON o CSV.
- Rectificación (art. 16): edición por el propio usuario desde un portal de clientes con autoservicio de datos.
- Supresión (art. 17): botón que dispara el bloqueo y registra quién lo pidió.
- Gestión interna: cola de solicitudes con fecha límite en el panel de administración para el equipo de soporte.
El encargado de tratamiento y las brechas de 72 horas
Un proveedor con acceso a datos de producción actúa como encargado del tratamiento, y el artículo 28.3 RGPD exige un contrato que incluya, entre otras obligaciones:
- Tratar los datos solo con instrucciones documentadas del responsable.
- Aplicar las medidas de seguridad del artículo 32.
- No recurrir a otro encargado sin autorización previa por escrito.
- Suprimir o devolver los datos al terminar el servicio.
Ante una brecha, el encargado avisa al responsable sin dilación indebida (art. 33.2) y el responsable la notifica a la autoridad de control, en España la AEPD, si es posible en un máximo de 72 horas desde que tiene constancia, salvo que sea improbable que suponga un riesgo (art. 33.1). Cumplir ese plazo exige logs que digan qué datos se vieron afectados.
CodeZone Pro Tip: esta consulta de PostgreSQL aplica una política de retención en dos fases, bloqueo y seudonimización, y deja constancia de cada ejecución.
-- Retención en dos fases: bloqueo (art. 32 LOPDGDD) y seudonimización posterior.
-- Plazos de ejemplo: los reales salen de tu registro de actividades (art. 30.1.f RGPD)
BEGIN;
-- Fase 1: clientes sin actividad en 6 años quedan bloqueados y la app deja de mostrarlos
WITH bloqueados AS (
UPDATE clientes
SET bloqueado_en = now()
WHERE ultima_actividad < now() - interval '6 years'
AND bloqueado_en IS NULL
RETURNING id
)
INSERT INTO registro_retencion (fase, ids, total)
SELECT 'bloqueo', array_agg(id), count(*) FROM bloqueados HAVING count(*) > 0;
-- Fase 2: vencido el plazo de prescripción, se eliminan los identificadores directos.
-- El id se conserva para que pedidos y facturas sigan cuadrando sin saber quién era
WITH seudonimizados AS (
UPDATE clientes
SET nombre = 'cliente-' || id, email = NULL, telefono = NULL, nif = NULL,
seudonimizado_en = now()
WHERE bloqueado_en < now() - interval '5 years'
AND seudonimizado_en IS NULL
RETURNING id
)
INSERT INTO registro_retencion (fase, ids, total)
SELECT 'seudonimizacion', array_agg(id), count(*) FROM seudonimizados HAVING count(*) > 0;
COMMIT;Programada como tarea diaria, la retención deja de depender de que alguien se acuerde. La tabla `registro_retencion` demuestra ante una inspección que los plazos del registro de actividades se cumplen.
Lo Que Cuesta Añadir la Privacidad al Final
Una aplicación sin plazos de conservación acumula datos que nadie necesita, y cada uno amplía el impacto de una brecha. Incorporar el RGPD en el diseño cuesta unas columnas y un proceso programado; incorporarlo después cuesta una migración.
Si tu software trata datos de clientes o empleados y no sabes cómo responde a una solicitud de supresión, revisamos contigo la privacidad de tu aplicación.
