ENS, NIS2, DORA, AI Act, RGPD, eIDAS, Data Act, ISO 27001, NIST, CIS. Para muchos equipos técnicos, el mapa regulatorio empieza a parecer una lista interminable de siglas que llega siempre tarde a la mesa: cuando hay una licitación, una auditoría, un cliente financiero, una certificación pendiente o un incidente de seguridad.

El error habitual es tratar cada marco como si fuera un proyecto separado. Un equipo monta el ENS, otro prepara ISO 27001, legal revisa RGPD, seguridad habla de NIS2, producto empieza a mirar el AI Act y compras pregunta por proveedores. El resultado suele ser una pila de documentos, controles duplicados y evidencias repartidas entre correos, tickets, hojas de cálculo y herramientas que no se hablan entre sí.

Para una organización tecnológica, la forma más útil de mirar el cumplimiento no es empezar por la norma, sino por la arquitectura real: qué servicios presta, qué datos trata, qué infraestructura usa, qué terceros intervienen, qué clientes dependen de ella y qué impacto tendría una caída, una fuga de datos o una decisión automatizada mal gobernada.

De la matriz legal al mapa técnico de servicios

La aplicabilidad regulatoria rara vez depende de una única etiqueta. Una empresa puede ser a la vez proveedor cloud, MSP, desarrollador de software, encargado de tratamiento, proveedor de una entidad financiera, operador de una plataforma de IA y adjudicatario de un contrato público. Cada rol arrastra obligaciones distintas.

El Esquema Nacional de Seguridad se regula en España por el Real Decreto 311/2022 y afecta a sistemas que manejan información o servicios en el ámbito de la administración electrónica y sus proveedores. NIS2, la Directiva (UE) 2022/2555, eleva el nivel común de ciberseguridad en la Unión Europea para entidades esenciales e importantes. DORA, el Reglamento (UE) 2022/2554, se centra en la resiliencia operativa digital del sector financiero y en el control de riesgos TIC. El Reglamento de IA, Reglamento (UE) 2024/1689, establece un enfoque basado en riesgos para sistemas de inteligencia artificial.

A esa capa se suman normas horizontales sobre privacidad, identidad digital, datos y reutilización. El RGPD regula el tratamiento de datos personales; eIDAS cubre identificación electrónica y servicios de confianza; el Data Act establece reglas sobre acceso y uso de datos, y el Data Governance Act ordena determinados mecanismos de gobernanza y compartición de datos en la UE.

La consecuencia práctica es que el inventario de servicios importa tanto como el inventario de activos. No basta con saber cuántos servidores, contenedores, buckets, clústeres o bases de datos existen. Hay que saber qué servicio soporta cada activo, qué datos procesa, qué cliente lo usa, qué SLA tiene, qué proveedor interviene y qué obligación contractual o normativa cuelga de esa pieza.

Un CRM con datos personales no se gobierna igual que una plataforma de scoring con IA. Un backup de un ayuntamiento no tiene el mismo contexto que un sistema interno de analítica. Un proveedor cloud que presta servicios a una entidad financiera no asume el mismo nivel de exposición que una web corporativa. La arquitectura es la que termina explicando la norma.

El núcleo común: identidad, logs, parches, evidencias y gobierno

Aunque cada marco regulatorio tenga su propio lenguaje, muchos requisitos aterrizan en controles muy parecidos. Gestión de riesgos, gobierno, control de accesos, autenticación robusta, segregación de funciones, inventario de activos, cifrado, gestión de vulnerabilidades, monitorización, respuesta a incidentes, continuidad, proveedores, formación y auditoría.

Para los equipos técnicos, esto permite construir una base común. No tiene sentido desplegar un sistema de evidencias para ENS, otro para ISO 27001, otro para DORA y otro para NIS2 si todos van a preguntar por los mismos puntos: quién accede, con qué privilegios, qué cambios se han aplicado, qué vulnerabilidades están abiertas, cuándo se probó el backup, qué ocurrió durante un incidente y quién aprobó una excepción.

El cumplimiento moderno se parece cada vez más a ingeniería de plataforma. IAM, MFA, PAM, SIEM, EDR, CMDB, ticketing, escáneres de vulnerabilidades, pipelines CI/CD, repositorios Git, inventario cloud, gestión de secretos, copias de seguridad y herramientas GRC tienen que formar parte de la misma conversación.

Un ejemplo sencillo: la gestión de vulnerabilidades. En una organización madura, no debería consistir en exportar un PDF mensual y guardarlo para la auditoría. Debería haber inventario actualizado, criticidad por servicio, responsable técnico, SLA de remediación, excepciones aprobadas, trazabilidad en ticketing y evidencias de cierre. Ese mismo flujo puede servir para ENS, NIS2, ISO 27001, DORA o requisitos contractuales de cliente.

Lo mismo ocurre con los logs. No basta con almacenar eventos. Hay que definir qué se registra, durante cuánto tiempo, con qué integridad, quién puede acceder, cómo se correlacionan alertas y cómo se reconstruye una línea temporal tras un incidente. Para seguridad es operación diaria; para legal y compliance es capacidad probatoria.

En IA aparece un reto adicional. El AI Act obliga a pensar en riesgo, uso previsto, documentación, supervisión humana, datos, trazabilidad y control del ciclo de vida. En términos técnicos, eso implica pasar de “hemos integrado un modelo” a “sabemos qué modelo usamos, con qué datos, para qué finalidad, bajo qué controles, con qué métricas, qué límites tiene y quién responde si falla”.

Compliance as code: menos carpetas y más operación

El siguiente salto será convertir parte del cumplimiento en controles verificables de forma continua. No todo puede automatizarse, pero muchas evidencias sí pueden generarse desde la operación.

Una política de MFA vale poco si la consola de identidad muestra cuentas privilegiadas sin segundo factor. Un procedimiento de backups no sirve si no hay pruebas de restauración. Un compromiso de cifrado se queda corto si aparecen buckets públicos, volúmenes sin cifrar o secretos en repositorios. Una matriz de proveedores no aporta mucho si no enlaza con contratos, evaluaciones de riesgo, subencargados y planes de salida.

La lógica de compliance as code consiste en acercar el cumplimiento al mismo lugar donde se despliega y opera la tecnología. Políticas en repositorios, controles en pipelines, validaciones de infraestructura como código, detección de configuraciones inseguras, evidencias automáticas y cuadros de mando por servicio. No sustituye al análisis jurídico ni al criterio del CISO, pero reduce el desfase entre lo que la empresa dice que hace y lo que sus sistemas hacen realmente.

Esto también cambia la relación entre legal y tecnología. El abogado especializado en tecnología ya no puede trabajar solo con cláusulas. Necesita entender dependencias cloud, tratamiento de datos, roles de proveedor, registros de actividad, arquitectura de IA, incidentes y cadena de suministro. El equipo técnico, por su parte, no puede ver la regulación como una molestia externa. Muchas obligaciones son, en el fondo, buenas prácticas de ingeniería y seguridad llevadas al plano exigible.

El reto para 2026 no será aprenderse todas las siglas. Será construir un modelo que permita responder rápido a una pregunta concreta: para este servicio, con estos datos, estos clientes y estos proveedores, qué riesgos tenemos, qué controles los cubren y qué evidencias podemos enseñar mañana.

Las organizaciones que lo resuelvan bien no tendrán treinta programas de cumplimiento en paralelo. Tendrán una base común sólida y capas específicas según servicio, sector y riesgo. Esa es la diferencia entre sobrevivir a una auditoría y operar con una arquitectura preparada para un entorno regulado.

Preguntas frecuentes

¿Qué debe hacer primero un equipo técnico ante tantas normas?
Mapear servicios y dependencias. Antes de mirar controles, conviene saber qué sistemas soportan cada servicio, qué datos tratan, qué clientes los usan y qué terceros intervienen.

¿Sirve ISO 27001 para cubrir ENS, NIS2 o DORA?
Ayuda mucho como base de gestión de seguridad, pero no sustituye el análisis específico de cada marco. ENS, NIS2 y DORA tienen obligaciones propias que deben mapearse de forma expresa.

¿Qué significa compliance as code?
Es aplicar controles de cumplimiento de forma automatizada o semiautomatizada dentro de la operación técnica: pipelines, infraestructura como código, inventario, monitorización, gestión de accesos y evidencias generadas desde sistemas reales.

¿Cómo afecta el AI Act a los equipos tecnológicos?
Obliga a documentar y gobernar mejor los sistemas de IA, especialmente si son de alto riesgo. Esto incluye finalidad, datos, supervisión humana, trazabilidad, control de cambios, evaluación de riesgos y responsabilidades.

Fuente: Abogados Contratos