Guía RGPD: qué regula, qué no y por qué importa en ciberseguridad

Si trabajas en tecnología o tienes una empresa en Europa, hay cuatro letras que probablemente te den más miedo que un kernel panic un viernes a las 17:00: RGPD (o GDPR para los amigos angloparlantes).

Vamos a ser sinceros: leer textos legales suele ser el remedio más eficaz contra el insomnio. Pero en este caso, ignorar el Reglamento General de Protección de Datos no te dará sueño, te dará pesadillas. Y multas. Muchas multas.

Así que vamos a destripar esto sin jerga de abogado de los años 50, para que entiendas qué diablos tienes que hacer con los datos de tus usuarios antes de que la autoridad de control te toque la puerta.

Introducción: ¿Por qué tanto revuelo?

El RGPD cambió las reglas del juego en mayo de 2018. Antes, las empresas trataban los datos personales como si fuera un buffet libre: coge todo lo que puedas y ya veremos para qué sirve. Ahora, el usuario es el dueño de sus datos (que más quisiéramos) y tú eres solo un custodio temporal.

Básicamente, el reglamento dice: «Si vas a ganar dinero con la información de la gente, al menos ten la decencia de protegerla y decirles qué haces con ella». Parece lógico, ¿verdad? Pues a medio internet le pilló por sorpresa.

El Terreno de Juego: ¿A quién aplica esto?

Aquí es donde la gente se confunde. «¿Si mi empresa está en España pero mi servidor está en la nube y mi cliente en Tumbuctú, me aplica?»

La respuesta corta es: Sí. La respuesta larga es el Artículo 3 del RGPD, pero veamos un ejemplo práctico.

Caso Práctico: El LMS «Cervantes Global»

Imagina una empresa llamada Cervantes Global S.L., con sede en Madrid. Tienen una plataforma de aprendizaje (LMS) alojada en servidores en España.

• Sus usuarios: Estudiantes registrándose desde Brasil, Perú, Sudáfrica y Francia.
• La duda: «¿Tengo que aplicar el RGPD a un usuario que se conecta desde Lima o Ciudad del Cabo?»
• La realidad: SÍ.

Al ser Cervantes Global S.L. una empresa establecida en la Unión Europea (España), el RGPD aplica a TODO su tratamiento de datos, independientemente de dónde viva el usuario o de su nacionalidad.

• Al usuario de Brasil, además, le podría aplicar su propia ley local (la LGPD), que es prima hermana del RGPD.
• Al usuario de Sudáfrica, le proteges bajo el paraguas del RGPD porque tú estás en la UE.

Moraleja: Si tu empresa está en suelo europeo, no importa si tus clientes son marcianos; sus datos se tratan con estándares europeos.

Los 7 «Mandamientos» del RGPD (Principles)

Si no cumples estos principios, estás construyendo tu seguridad sobre arena.

1. Licitud, lealtad y transparencia: No mientas. Di qué haces con los datos en un idioma que entienda un humano, no solo un abogado.
2. Limitación de la finalidad: Si pides el email para enviar una factura, no lo uses para venderle viagra.
3. Minimización de datos (Data Minimization): Esta es clave. ¿Necesitas la fecha de nacimiento para que alguien se descargue un PDF? No. Pues no la pidas. Recopilar datos «por si acaso» es como guardar basura en casa «por si acaso»: Diógenes digital.
4. Exactitud: Los datos deben ser correctos. Tener una base de datos llena de errores no sirve de nada.
5. Limitación del plazo de conservación: No puedes guardar los datos para siempre. Si el cliente se fue hace 10 años, borra eso. Tampoco lo borres antes del plazo regulado de retención obligatoria.
6. Integridad y confidencialidad: Aquí entramos nosotros. Seguridad, cifrado, control de acceso, anonimización. Si proteges los datos con una contraseña tipo «admin123», te has saltado este punto.
7. Responsabilidad proactiva (Accountability): No basta con hacerlo bien, tienes que demostrar que lo haces bien. Documenta todo.

Derechos del Interesado: El usuario tiene el poder

El RGPD le dio a los usuarios una caja de herramientas para molestarnos… digo, para ejercer sus derechos (Data Subject Rights).

• Derecho de Acceso: «¿Qué sabes de mí?» Tienes que darle una copia de sus datos.
• Derecho de Rectificación: «Mi nombre se escribe con H». Tienes que corregirlo.
• Derecho de Supresión (Derecho al Olvido): «Bórrame de tu existencia». Salvo que tengas una obligación legal para conservar los datos (como facturación), debes eliminarlos.
  • En nuestro ejemplo del LMS: Si el usuario de Perú pide que le borres, Cervantes Global debe borrarlo, aunque el usuario esté en los Andes.
• Derecho a la Portabilidad: Poder llevarse sus datos a otro proveedor (ideal para irse a la competencia, qué alegría).

El Reparto: Responsable, Encargado y el DPO

Para entender esto, imaginemos una película:

• Responsable del Tratamiento (Data Controller): Es el que decide el «qué» y el «para qué». En nuestro ejemplo, Cervantes Global S.L. es el Responsable. Ellos deciden vender cursos y captar alumnos.
• Encargado del Tratamiento (Data Processor): Es el que trata los datos por orden del Responsable. Si Cervantes Global usa AWS o Azure para alojar el LMS, Amazon o Microsoft son los Encargados.
  • Ojo: Si contratas una gestoría externa para las nóminas, ellos son Encargados. Necesitas un contrato vinculante con ellos.
• Delegado de Protección de Datos (Data Protection Officer – DPO): Es el árbitro. Supervisa que se cumpla la ley. No todas las empresas necesitan uno, pero si tratas datos a gran escala o datos sensibles (salud, penales, etc.), es obligatorio. Es la persona a la que todos miran cuando hay una brecha de seguridad.

Como esto hace bola y cae mucho en todas las certificaciones entry-level y mid-level de ciber y cumplimiento, recuerda bien esta tabla:

¡Cuidado! Es común confundir el término «Data Owner».

• En el contexto estricto del RGPD, el dueño (owner) de los datos es siempre la persona física (Data Subject).
• En entornos corporativos de TI, a veces se llama «Data Owner» al jefe de departamento que recolecta los datos, pero legalmente esa figura es el Data Controller (Responsable).

En otros contextos más internacionales (y en el examen CompTIA Sec+), el Data Owner es un rol de gestión (generalmente un directivo o jefe de departamento, que decide, no ejecuta) que tiene la responsabilidad final sobre un conjunto de datos específico dentro de la organización. Sus tareas principales son:

• Determinar la clasificación de la información (ej. Confidencial, Secreto, Público).
• Decidir los requisitos de seguridad y quién tiene permiso de acceso.
• Delegar la implementación técnica de esas protecciones en el Data Custodian (Custodio de Datos) o el administrador de sistemas.

Privacidad desde el Diseño y por Defecto (Privacy by Design)

Esto no significa poner un banner de cookies y rezar. Significa que la seguridad debe estar integrada en el ciclo de desarrollo de software (SDLC) desde el minuto cero.

Si estás desarrollando el LMS, no puedes pensar en la seguridad la semana antes del lanzamiento. Debes aplicar conceptos de Seguridad de Aplicaciones Web para evitar que, por ejemplo, un fallo de inyección SQL exponga toda la tabla de usuarios.

Técnicas obligatorias:

• Seudonimización (Pseudonymization): Cambiar nombres por códigos identificadores, de forma que sin una clave adicional no se sepa quién es quién.
• Cifrado (Encryption): Tanto en tránsito (HTTPS/TLS) como en reposo. Aquí es vital una buena gestión de claves. Si no tienes claro cómo funciona esto, te recomiendo repasar los fundamentos de Criptografía y entender cómo una PKI (Infraestructura de Clave Pública) asegura que las comunicaciones sean privadas de verdad.

Gestión de Incidentes: La carrera de las 72 horas

Supongamos que pasa lo peor. Un atacante entra en tu LMS y se descarga la base de datos de alumnos de África y Latam. ¿Qué haces?

1. No entres en pánico, cabeza fria.
2. El reloj corre: Tienes 72 horas desde que te enteras para notificar a la Autoridad de Control (en España, la AEPD) si el incidente supone un riesgo para los derechos de las personas.
3. Comunicación a los usuarios: Si el riesgo es alto (ej: se filtraron contraseñas o datos bancarios), tienes que avisar a los usuarios afectados. Sí, a Juan en Perú también. Dile que cambie su contraseña.

Las Multas: Cuando el dolor es económico

Aquí es donde el RGPD saca los dientes. Las multas pueden llegar hasta:

• 10 millones de euros o el 2% de la facturación global anual (para infracciones leves).
• 20 millones de euros o el 4% de la facturación global anual (para las graves).

Se aplica la cuantía que sea mayor. Para Google o Facebook, el 4% es una barbaridad. Para una Pyme, 20 millones es el cierre.

Checklist de Supervivencia RGPD para SysAdmins

Para que no digas que no te avisé, aquí tienes tu lista de tareas:

• Mapeo de datos: ¿Sabes dónde están todos los datos personales? (Bases de datos, backups, logs, Excel olvidado en el escritorio de RRHH).
• Política de Retención: Configura log rotation y scripts de purgado para no guardar datos más tiempo del necesario.
• Control de Accesos (IAM): Aplica el principio de mínimo privilegio (Least Privilege). Que el becario no tenga acceso root a la base de datos de producción, por favor.
• Cifrado: Activa BitLocker/FileVault en portátiles y cifra las BBDD.
• Backups: Prueba que tus copias de seguridad funcionan. Un backup que no se puede restaurar es solo un archivo pesado ocupando espacio.
• Formación: Enseña a tus empleados a no hacer clic en el enlace del «Príncipe Nigeriano». El factor humano siempre es el eslabón más débil.
• Auditorias internas y externas: Si, las odiamos, pero son necesarias.

Conclusión

El RGPD no es solo burocracia para fastidiar. En el fondo, nos obliga a tener una higiene digital que deberíamos haber tenido hace años. Para empresas como nuestro LMS «Cervantes Global», cumplir con el reglamento es un sello de calidad y confianza para sus usuarios en Latam y África.

Implementarlo cuesta trabajo, sí. Pero es mucho más barato que explicarle a la prensa por qué los datos de tus clientes están a la venta en la Dark Web.

Próximo paso para ti: Revisa ahora mismo los formularios de registro de tu web. ¿Estás pidiendo el teléfono «obligatorio» sin necesitarlo? Si es así, bórralo antes de que el espíritu del RGPD te visite esta noche.