El compliance de tecnología de la información es la disciplina que asegura que los sistemas de una organización cumplen el conjunto de normas legales, sectoriales y contractuales que les aplican. No es un trámite documental: es la traducción de obligaciones jurídicas en controles técnicos concretos —cifrado, registros de acceso, políticas de retención— que se puedan demostrar ante una autoridad de control. En el caso de los datos personales, esa exigencia tiene nombre propio: el RGPD, denominación en español del Reglamento General de Protección de Datos, que es exactamente el mismo texto que el anglosajón GDPR (General Data Protection Regulation).
Conviene deshacer una confusión habitual: GDPR y RGPD no son dos normas distintas, sino el mismo Reglamento (UE) 2016/679 nombrado en inglés y en español. En España, además, lo desarrolla y complementa la Ley Orgánica 3/2018 de Protección de Datos Personales y Garantía de los Derechos Digitales (LOPDGDD), que añade matices propios como la regulación de los derechos digitales en el ámbito laboral.
Principios del RGPD que el sistema debe encarnar
El artículo 5 del Reglamento fija seis principios que dejan de ser teoría cuando se diseña un sistema. La minimización obliga a recoger solo los datos necesarios: una base de datos que almacena el DNI «por si acaso» ya incumple. La limitación de la finalidad impide reutilizar datos recogidos para una cosa en otra distinta sin nueva base legitimadora. La limitación del plazo de conservación exige borrar o anonimizar cuando el dato deja de ser necesario, lo que se traduce en políticas de retención automatizadas. Y la integridad y confidencialidad impone seguridad técnica adecuada. El artículo 25 añade la protección de datos desde el diseño y por defecto: la privacidad no se atornilla al final del proyecto, se incorpora desde la arquitectura.
Privacy by design en la práctica técnica
Llevar el «desde el diseño» a la ingeniería real significa decisiones concretas. La seudonimización separa los identificadores directos de los datos de comportamiento, de modo que una filtración parcial no reidentifique a las personas. La anonimización efectiva —irreversible, no un simple borrado de la columna del nombre— saca el dato del ámbito del Reglamento. El cifrado en reposo y en tránsito con gestión adecuada de claves protege frente a accesos no autorizados. Y el control de acceso basado en roles (RBAC) con principio de mínimo privilegio garantiza que cada persona solo ve lo que su función requiere, dejando registro auditable de cada acceso.
La distinción entre seudonimización y anonimización es más que terminológica y se confunde a menudo. Un dato seudonimizado sigue siendo dato personal a efectos del RGPD, porque existe una clave que permite reidentificar al titular; solo está protegido frente a quien no posee esa clave. Un dato verdaderamente anonimizado, en cambio, ya no permite la reidentificación por ningún medio razonable y queda fuera del Reglamento. La consecuencia práctica es relevante: muchas organizaciones creen haber anonimizado cuando en realidad solo han seudonimizado, y siguen sujetas a todas las obligaciones. La anonimización robusta exige técnicas como la generalización, la supresión de cuasi-identificadores o la privacidad diferencial, y debe resistir intentos de reidentificación por cruce con otras fuentes —el riesgo de que un código postal, una fecha de nacimiento y un sexo identifiquen a una persona concreta es real y está documentado.
Auditoría de sistemas y marcos de referencia
Una auditoría de compliance IT contrasta el estado real de los sistemas con un marco de control reconocido. El más extendido para seguridad de la información es ISO/IEC 27001, que define un sistema de gestión de la seguridad de la información (SGSI) certificable y, en su anexo de controles, prácticas concretas. Para la privacidad específicamente existe la extensión ISO/IEC 27701, que añade los controles de un sistema de gestión de la información de privacidad (PIMS). En entornos cloud, marcos como el CIS Benchmark y el Cloud Controls Matrix aterrizan los controles a configuraciones verificables. La auditoría produce evidencias: capturas de configuración, extractos de logs, matrices de roles y registros de tratamiento.
El valor de apoyarse en estos marcos es que convierten obligaciones jurídicas abstractas en controles verificables y repetibles. El RGPD exige «medidas técnicas y organizativas apropiadas», una fórmula deliberadamente abierta; la ISO 27001 traduce esa exigencia en controles concretos sobre gestión de accesos, cifrado, copias de seguridad, gestión de incidentes y continuidad de negocio, cada uno con su evidencia asociada. Cuando llega una inspección o una auditoría de cliente, la organización no improvisa: exhibe el inventario de controles, su estado de implantación y las pruebas de que funcionan. Esa es la diferencia entre afirmar que se cumple y demostrarlo. La auditoría debe ser, además, recurrente: un control que funcionaba hace un año puede haberse desactivado tras una migración, y solo una revisión periódica lo detecta antes de que se convierta en una brecha.
Pasos para un programa de compliance IT
- Inventariar los tratamientos. Elaborar y mantener el registro de actividades de tratamiento del artículo 30, base de todo lo demás: qué datos, con qué finalidad, dónde se almacenan y a quién se ceden.
- Determinar la base legitimadora. Cada tratamiento necesita una de las seis bases del artículo 6 (consentimiento, contrato, obligación legal, interés vital, interés público o interés legítimo).
- Evaluar el riesgo. Cuando el tratamiento entraña alto riesgo, realizar una Evaluación de Impacto en Protección de Datos (EIPD/DPIA) conforme al artículo 35.
- Implantar controles técnicos. Cifrado, RBAC, registros de auditoría, copias de seguridad cifradas y políticas de retención automatizadas.
- Preparar la respuesta a brechas. Definir el procedimiento para notificar a la AEPD en 72 horas (artículo 33) y a los afectados cuando proceda (artículo 34).
- Designar un DPO si aplica. El delegado de protección de datos es obligatorio para ciertos tratamientos (artículo 37) y recomendable en muchos otros.
Errores comunes
El error más recurrente es confundir tener documentación con cumplir: una política de privacidad impecable en el sitio web no sirve de nada si el sistema sigue conservando datos diez años sin base que lo justifique. El segundo es tratar el consentimiento como un cajón de sastre, cuando suele ser la base legitimadora más frágil y revocable; muchas veces el contrato o el interés legítimo son más sólidos y adecuados. El tercero es ignorar a los encargados de tratamiento: cada proveedor cloud o SaaS que procesa datos por cuenta de la organización exige un contrato del artículo 28 y, si está fuera del Espacio Económico Europeo, garantías de transferencia internacional. El cuarto es descubrir el procedimiento de notificación de brechas el día en que ocurre la brecha, con el reloj de las 72 horas ya en marcha.
Comparativa de marcos aplicables
| Marco / norma | Ámbito | Carácter | Certificable |
|---|---|---|---|
| RGPD / GDPR (UE 2016/679) | Datos personales | Obligatorio | No (es ley) |
| LOPDGDD (LO 3/2018) | Datos personales en España | Obligatorio | No (es ley) |
| ISO/IEC 27001 | Seguridad de la información | Voluntario | Sí |
| ISO/IEC 27701 | Gestión de privacidad (PIMS) | Voluntario | Sí (extensión de 27001) |
Preguntas frecuentes
¿GDPR y RGPD son normas diferentes? No. Son el mismo Reglamento (UE) 2016/679: GDPR es su nombre en inglés y RGPD en español. Una empresa que cumple uno cumple el otro por definición.
¿Cuánto puede sancionar la AEPD? El RGPD prevé multas de hasta 20 millones de euros o el 4 % de la facturación anual mundial del grupo, la cifra que sea mayor, para las infracciones más graves. Las sanciones reales se gradúan según gravedad, intencionalidad y medidas adoptadas.
¿Toda empresa necesita un DPO? No. Es obligatorio para autoridades públicas y para quienes realizan observación sistemática a gran escala o tratan categorías especiales de datos a gran escala. Fuera de esos supuestos, designarlo es voluntario, aunque a menudo recomendable.
¿Certificar ISO 27001 garantiza el cumplimiento del RGPD? No automáticamente. La ISO 27001 aporta una base de seguridad sólida y demuestra diligencia, pero el cumplimiento del RGPD exige además controles específicos de privacidad que recoge mejor la ISO 27701.
¿Qué plazo hay para notificar una brecha de seguridad? El artículo 33 del RGPD fija un máximo de 72 horas desde que el responsable tiene conocimiento de la brecha para notificarla a la autoridad de control, salvo que sea improbable que entrañe un riesgo para los derechos de las personas. Si el riesgo es alto, el artículo 34 obliga además a comunicarlo a los propios afectados sin dilación indebida. Tener el procedimiento ensayado de antemano —quién decide, qué se documenta, cómo se contacta con la AEPD— es lo que permite cumplir ese plazo bajo la presión real de un incidente.
¿Aplica el RGPD a una empresa fuera de la Unión Europea? Sí, cuando ofrece bienes o servicios a personas en la UE o monitoriza su comportamiento, según el principio de extraterritorialidad del artículo 3. La ubicación de los servidores no exime: lo determinante es a quién van dirigidos los datos.
En Summum Sistemas planteamos el compliance IT como ingeniería con respaldo jurídico, no como papeleo defensivo. El RGPD no penaliza por sufrir un incidente, sino por no haber implantado las medidas razonables que lo habrían prevenido o contenido. Esa es la clave práctica: un programa bien construido convierte cada obligación legal en un control técnico verificable —un log que se puede exhibir, una política de retención que se ejecuta sola, un contrato de encargo firmado con cada proveedor— de modo que, llegado el día de una auditoría o de una brecha, la organización pueda demostrar diligencia con evidencias y no con buenas intenciones. Cumplir no es tener los documentos; es poder probar que el sistema hace lo que los documentos prometen.