Dinamarca es uno de los países más digitalizados del mundo, y precisamente por eso lo ocurrido este otoño importa mucho más allá de sus fronteras. En pocas semanas, dos incidentes han expuesto datos de millones de personas, y ninguno empezó con un ataque sofisticado al sistema principal. Los dos empezaron en los márgenes.
Trabajamos con empresas de Dinamarca y Suecia, así que aquí va un resumen de lo que se sabe y las lecciones prácticas para cualquier organización, también en España.
El registro CPR: 8,8 millones de personas
El 5 de octubre de 2026, las autoridades danesas anunciaron un incidente grave en el registro CPR, el registro central de todas las personas con número de identificación danés (el equivalente a nuestro DNI).
- Se usó el acceso legítimo de una empresa danesa para consultar datos del registro.
- Durante unos diez días de septiembre se hicieron muchísimas consultas automatizadas.
- Afecta a unos 8,8 millones de personas, vivas y fallecidas: nombres, direcciones y números CPR. En las personas con protección de nombre y dirección, estos datos quedaron fuera.
- Lo detectó un empleado de la administración del registro el 2 de octubre. Se cortó el acceso de la empresa y se comunicó a la autoridad de protección de datos y a la policía.
Todavía se investiga cómo consiguieron los atacantes ese acceso y qué han hecho con los datos.
La Universidad de Copenhague: 525.000 personas
El 23 de octubre, la Universidad de Copenhague (KU) comunicó un ciberataque detectado el día 20.
- Los atacantes entraron por uno de sus entornos de pruebas.
- Accedieron a datos de unas 525.000 personas: nombres, números CPR, teléfonos y correos personales.
- También se vieron comprometidos los PIN de las tarjetas de identificación de unas 20.000 personas, que ya tienen PIN nuevos.
- Se apagaron varios sistemas administrativos por precaución. El 27 de octubre, la universidad aclaró que lo que parecía un segundo ataque estaba ligado al primero.
La Universidad Técnica de Dinamarca (DTU) y la Universidad de Aarhus también han sufrido ataques en las últimas semanas, y la ministra de Educación Superior convocó a los responsables de las ocho universidades danesas a una reunión de seguridad.
Cinco lecciones para cualquier empresa
1. El acceso de tus socios también es tu superficie de ataque
El registro CPR no fue «hackeado» en el sentido clásico: alguien usó un acceso al que una empresa tenía derecho. Cualquier empresa que da acceso a sus datos a socios, proveedores o integraciones debería preguntarse:
- ¿Cada socio tiene acceso solo a lo que necesita?
- ¿Hay límites de volumen (consultas por hora o por día)?
- ¿El acceso está protegido con doble factor y se revisa periódicamente?
2. Detectar lo raro, de forma automática
Una avalancha de consultas automatizadas es justo el tipo de patrón que un sistema puede detectar en minutos. Alertas por volumen, horario u origen inusuales convierten diez días en diez minutos.
3. Los entornos de pruebas también son producción
La brecha de la KU empezó en un entorno de pruebas. Estos sistemas suelen estar menos protegidos, pero están conectados a la red real y a veces contienen datos reales. Usa datos ficticios o anonimizados para probar y protege los entornos de pruebas igual que los de producción.
4. No guardes datos que no necesitas
Números de identificación, teléfonos personales y correos privados son muy valiosos para un atacante. Cada dato que no guardas es un dato que no se puede filtrar. Revisa qué recoges y cuánto tiempo lo conservas.
5. Ten un plan para el día después
Con el RGPD, una brecha de datos personales normalmente debe comunicarse a la autoridad de protección de datos en 72 horas; en España, a la AEPD. Decide antes quién toma las decisiones, quién informa a los clientes y cómo, y a quién llamas para la parte técnica. Y avisa a tus clientes del phishing que suele llegar después de una filtración.
El hilo común
Ninguno de los dos incidentes necesitó una vulnerabilidad brillante. Los dos aprovecharon puntos débiles alrededor del sistema principal: el acceso de un socio y un servidor de pruebas. Es el mismo mensaje que la reciente vulnerabilidad PHP2Shell: la seguridad depende de toda la cadena, también de las partes menos vistosas.
Cómo te ayudamos
En PDCG ayudamos a las empresas a revisar cómo están conectados sus sistemas: quién tiene acceso a qué, qué está expuesto, cómo están montados los entornos de pruebas y dónde se guardan los datos. Trabajamos con infraestructura europea y con la minimización de datos en mente. Mira consultoría tecnológica y hosting y cloud europeo, o escríbenos.
Artículo basado en la información publicada hasta el 27 de octubre de 2026. Las dos investigaciones siguen abiertas; lo actualizaremos si hay novedades.