Cumplimiento NIS2 y RGPD: qué implica para tu desarrollo web

NIS2 y RGPD: la normativa que afecta a tu desarrollo

Si desarrollas software o gestionas plataformas web en Europa, dos normativas condicionan tus decisiones técnicas: el RGPD (en vigor desde 2018) y la Directiva NIS2 (cuyo plazo de transposición a legislación nacional venció el 17 de octubre de 2024). No son solo temas legales: tienen implicaciones técnicas directas que tu equipo de desarrollo debe conocer. Si tu empresa es proveedora tecnológica, revisa también las obligaciones específicas de NIS2 para empresas tecnológicas.

Adecuar tu desarrollo a estas normativas forma parte de la seguridad informática de tu organización; te acompañamos en el cumplimiento del ENS, la ISO 27001 y NIS2.

A estas dos se ha sumado una tercera que mucha gente todavía no tiene en el radar y que, para quien escribe código, es probablemente la más directa de las tres: el Cyber Resilience Act (CRA), cuyas obligaciones de notificación de vulnerabilidades ya están en vigor desde el 11 de septiembre de 2026. Este artículo repasa qué exige cada una, en qué punto está realmente cada norma a día de hoy y qué se traduce en trabajo concreto para tu equipo.

RGPD: lo que tu aplicación debe cumplir

El RGPD afecta a cualquier aplicación que maneje datos personales de ciudadanos europeos. Implicaciones técnicas: consentimiento explícito para cookies y tracking (implementar banner de consentimiento que realmente bloquee scripts antes del consentimiento), derecho de acceso y portabilidad (tu API debe poder exportar todos los datos de un usuario), derecho al olvido (capacidad de eliminar datos de un usuario de todos los sistemas), y privacidad por diseño (minimización de datos, cifrado, pseudonimización).

La base de legitimación se decide antes de escribir el código

El error más común no está en el banner de cookies, sino antes: tratar todos los datos bajo la misma justificación. El RGPD exige una base de legitimación por cada finalidad de tratamiento, y esa decisión cambia el diseño. Si el tratamiento se apoya en el consentimiento, necesitas poder demostrar cuándo y cómo se obtuvo, lo que implica guardar un registro con marca temporal y versión del texto aceptado. Si se apoya en la ejecución de un contrato, el consentimiento no procede y pedirlo induce a error. Y si se apoya en el interés legítimo, hace falta una ponderación documentada y un mecanismo de oposición real, no un enlace decorativo.

En la práctica esto significa que el modelo de datos debería llevar la finalidad asociada al dato, no solo el dato. Una tabla de usuarios donde el correo sirve a la vez para autenticar, para facturar y para enviar campañas comerciales es una tabla que no sabe responder a una solicitud de oposición parcial sin tocar código.

Los derechos del interesado son endpoints, no correos electrónicos

Acceso, rectificación, supresión, portabilidad, limitación y oposición tienen un plazo de respuesta de un mes. Resolverlos a mano funciona con diez solicitudes al año y deja de funcionar en cuanto el producto crece. Lo sostenible es tratarlos como funcionalidad del producto desde el principio:

• Portabilidad: un export que devuelva los datos en un formato estructurado y de uso común (JSON o CSV), no un PDF maquetado.
• Supresión: un borrado que recorra todos los sistemas, incluidos los que suelen olvidarse: réplicas de lectura, data warehouse, backups, logs de aplicación, colas de mensajería, CRM y herramientas de soporte o analítica de terceros.
• Trazabilidad: registro de qué se hizo, cuándo y quién lo ejecutó, porque la carga de la prueba del cumplimiento recae en el responsable del tratamiento.

Backups, logs y el borrado que nadie implementa

El derecho al olvido choca de frente con la política de retención de copias de seguridad, y es el punto donde más auditorías se tuercen. La salida razonable no es borrar dentro del backup (técnicamente inviable en la mayoría de arquitecturas), sino documentar que las copias tienen una retención definida y acotada, que no se usan para otra cosa que la restauración, y que si se restaura una copia se vuelve a aplicar la supresión pendiente. Eso exige mantener una lista de supresiones aplicadas, algo que conviene diseñar antes de la primera solicitud, no después.

Evaluación de impacto: cuándo es obligatoria

No todo proyecto necesita una evaluación de impacto relativa a la protección de datos, pero hay tres supuestos en los que es obligatoria y aparecen con frecuencia en desarrollo web: tratamiento a gran escala de categorías especiales de datos, observación sistemática de zonas de acceso público, y decisiones automatizadas con efectos jurídicos o que afecten significativamente a las personas. Este último supuesto se ha vuelto habitual con la incorporación de modelos de scoring y recomendadores: si el sistema decide quién obtiene un precio, un crédito o un acceso, la evaluación deja de ser opcional.

Transferencias internacionales: dónde está realmente el dato

Una arquitectura moderna reparte datos personales entre más proveedores de los que la documentación suele reflejar: el proveedor de correo transaccional, la herramienta de analítica, el CDN, el servicio de métricas de errores, el almacenamiento de objetos y el proveedor de IA que procesa texto del usuario. Cada uno de ellos es un encargado del tratamiento y cada salida del Espacio Económico Europeo necesita un mecanismo de transferencia válido. Mantener un inventario actualizado de subencargados y regiones no es burocracia: es lo primero que pide un cliente corporativo en su cuestionario de proveedor, y conviene tenerlo resuelto antes de la due diligence técnica de un contrato grande.

NIS2: seguridad como obligación legal

La Directiva NIS2 amplía significativamente el alcance de la normativa de ciberseguridad europea. Afecta a empresas medianas y grandes en sectores esenciales e importantes, incluyendo proveedores de servicios digitales. Exige: gestión de riesgos de ciberseguridad, medidas técnicas y organizativas de seguridad, notificación de incidentes en 24-72 horas, seguridad en la cadena de suministro, y formación en ciberseguridad.

En qué punto está la transposición en España

Conviene ser precisos, porque circula mucha confusión sobre esto. El plazo que la propia directiva fijaba a los Estados miembros era el 17 de octubre de 2024, y España no lo cumplió. El Consejo de Ministros aprobó el anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad el 14 de enero de 2025, pero el texto sigue en tramitación y no se ha publicado en el BOE. La Comisión Europea llegó a emitir un dictamen motivado contra España por el retraso en mayo de 2025.

¿Significa eso que NIS2 no aplica todavía? No exactamente, y aquí está el matiz que más decisiones condiciona. Mientras no haya ley nueva sigue vigente el Real Decreto-ley 12/2018, que transpuso la primera directiva NIS, y la supervisión continúa repartida: el CCN para el sector público y el Esquema Nacional de Seguridad, el INCIBE para el sector privado y los ciudadanos, y los reguladores sectoriales en ámbitos como finanzas o energía. El anteproyecto plantea unificar esa supervisión en un Centro Nacional de Ciberseguridad.

La lectura práctica para un equipo técnico es sencilla: el régimen sancionador concreto aún no está, pero los requisitos sí se conocen, y el plazo de adaptación que conceda la ley cuando se apruebe no va a ser suficiente para reconstruir la seguridad de una plataforma desde cero. Las empresas que están esperando al BOE para empezar son las que llegarán tarde. Si no sabes por dónde empezar, el recorrido básico está en nuestra guía de ciberseguridad para empresas.

Entidades esenciales e importantes: no es lo mismo

NIS2 distingue dos categorías, y la diferencia se nota tanto en la supervisión como en las sanciones. El criterio general combina sector y tamaño: operar en uno de los dieciocho sectores cubiertos y superar los 50 empleados o los 10 millones de euros de facturación anual. Las entidades esenciales (energía, transporte, banca, sanidad, agua, infraestructura digital, administración pública, espacio) están sometidas a supervisión proactiva. Las entidades importantes (servicios postales, residuos, química, alimentación, fabricación, plataformas digitales, investigación) solo se supervisan cuando hay indicios de incumplimiento.

El efecto cascada: por qué te afecta aunque no estés en la lista

Este es el punto que más subestiman las empresas pequeñas de desarrollo. NIS2 obliga a las entidades cubiertas a gestionar la seguridad de su cadena de suministro, y la forma en que eso se materializa es contractual: la entidad cubierta traslada sus requisitos a sus proveedores. Una agencia de quince personas que mantiene la plataforma de un operador logístico no es sujeto obligado, pero recibirá cláusulas de seguridad, plazos de notificación y derechos de auditoría en el próximo contrato. Lo mismo que ya ocurre con los proveedores tecnológicos de la Administración Pública y el ENS.

El Cyber Resilience Act: la norma que ya te obliga como fabricante de software

Si NIS2 regula a los operadores de servicios, el Cyber Resilience Act regula a quien fabrica el producto. Y su definición de producto con elementos digitales es amplia: aplicaciones móviles y de escritorio, sistemas operativos, bibliotecas y componentes. Las soluciones de procesamiento remoto de datos necesarias para que el producto funcione se consideran parte del propio producto, lo que mete en el perímetro a buena parte del SaaS.

El calendario es el siguiente. El reglamento entró en vigor el 10 de diciembre de 2024. Desde el 11 de junio de 2026 pueden notificarse los organismos de evaluación de la conformidad. Desde el 11 de septiembre de 2026 —es decir, ya— son exigibles las obligaciones de notificación del artículo 14. Y el 11 de diciembre de 2027 entra en aplicación plena el resto del reglamento, incluido el marcado CE de ciberseguridad.

La obligación que está viva ahora mismo es la de notificar vulnerabilidades explotadas activamente e incidentes graves, con una alerta temprana en 24 horas desde que se tiene conocimiento, una notificación más completa a las 72 horas con las medidas correctoras, y un informe final en 14 días una vez resuelto. Es un plazo más corto que el informe final de NIS2, que es de un mes.

Qué significan 24 horas en la práctica

Veinticuatro horas desde el conocimiento de la vulnerabilidad no es un plazo que se cumpla improvisando. Implica tener resuelto, de antemano, quién decide que algo es notificable, quién firma la notificación, por qué canal se envía y qué datos mínimos se mandan cuando todavía no se sabe casi nada. Y sobre todo implica que alguien se entere: si la detección depende de que un cliente abra un ticket un lunes por la mañana, el reloj lleva corriendo desde el viernes.

Esto es exactamente lo que convierte la monitorización de red y el registro centralizado de eventos en requisitos regulatorios y no en una mejora opcional de la infraestructura. Sin telemetría no hay detección, y sin detección el plazo se incumple por definición.

El SBOM deja de ser una buena práctica

El CRA exige a los fabricantes conocer y documentar los componentes de sus productos. Un inventario de software (SBOM) generado automáticamente en el pipeline deja de ser un detalle de madurez técnica y pasa a ser la única forma realista de responder a la pregunta que llega el día que se publica una vulnerabilidad crítica en una biblioteca muy extendida: ¿está esa versión en alguno de nuestros productos, y en cuáles? Las empresas que respondieron esa pregunta en horas durante los incidentes de los últimos años fueron las que ya tenían el inventario; las demás tardaron semanas.

Implicaciones técnicas concretas

Para cumplir con NIS2, tu desarrollo debe incluir: cifrado de datos en tránsito (TLS 1.3) y en reposo, autenticación multifactor para accesos privilegiados, registro de actividad y auditoría, plan de respuesta a incidentes con procedimientos documentados, backups y plan de continuidad de negocio, y evaluaciones de vulnerabilidad periódicas (pentesting).

Traducción a tareas de sprint

Esa lista suena a documento de consultoría hasta que se convierte en trabajo concreto. Estas son las tareas que de verdad acaban en el tablero:

• Gestión de secretos. Sacar credenciales, tokens y claves del repositorio y del fichero de entorno hacia un gestor con rotación y registro de acceso. Es el hallazgo número uno en casi toda auditoría de código.
• Control de acceso con mínimo privilegio. Revisar quién tiene acceso a producción y por qué, y eliminar las cuentas compartidas que nadie reconoce como suyas.
• Logs que sirvan para investigar. Centralizados, con reloj sincronizado, retención definida y, muy importante, sin datos personales innecesarios dentro: un log lleno de correos y DNI es una brecha esperando a ocurrir.
• Dependencias bajo control. Análisis automático de vulnerabilidades en cada build y una política explícita sobre qué se parchea y en cuánto tiempo.
• Copias restaurables. Una copia que nunca se ha restaurado no es una copia, es una suposición. Probar la restauración de forma periódica y dejar constancia. Es también la única defensa real frente al ransomware.
• Modelado de amenazas. Identificar vectores en la fase de diseño cuesta mucho menos que corregirlos en producción; herramientas como la Microsoft Threat Modeling Tool lo hacen abordable para equipos pequeños.

Privacy by Design en la práctica

Privacy by Design no es un concepto abstracto. Significa decisiones técnicas concretas: no recoger datos innecesarios, implementar retention policies automáticas (eliminar datos cuando ya no son necesarios), separar datos identificativos de datos de comportamiento, permitir la operación del servicio con la mínima cantidad de datos personales, y documentar el flujo de datos personales en la arquitectura.

Patrones que funcionan

Hay cuatro decisiones de diseño que resuelven la mayor parte del problema sin encarecer el desarrollo:

• Seudonimizar en el origen. Que la analítica y el almacén de datos trabajen con un identificador opaco y que la tabla que une ese identificador con la persona viva en un solo sitio, cifrada y con acceso restringido.
• Caducidad por defecto. Cada tipo de dato nace con una fecha de muerte y un proceso programado que la ejecuta. Es mucho más fiable que una limpieza manual anual que siempre se pospone.
• Entornos de preproducción sin datos reales. Copiar la base de producción a un entorno de pruebas es una práctica tan extendida como indefendible ante un auditor. Los datos sintéticos o anonimizados evitan el problema de raíz.
• Granularidad en la recogida. Pedir la fecha de nacimiento cuando basta con saber si la persona es mayor de edad, o la dirección completa cuando basta el código postal, genera una obligación que no hacía falta asumir.

El diagrama de flujo de datos: el documento que lo sostiene todo

Si solo pudiera mantenerse un documento de cumplimiento, debería ser el mapa de qué datos personales entran al sistema, dónde se almacenan, a qué terceros salen y cuánto tiempo permanecen. De ahí se derivan casi todos los demás: el registro de actividades de tratamiento, el inventario de encargados, la evaluación de impacto y la respuesta a una solicitud de supresión. Mantenerlo actualizado cuesta una hora por trimestre; reconstruirlo desde cero bajo la presión de una inspección cuesta semanas.

Cómo encaja esto con ISO 27001 y el ENS

La buena noticia es que estas normas no son compartimentos estancos. Los controles que pide NIS2 se solapan en gran medida con los de la ISO 27001, y quien ya tiene un sistema de gestión de la seguridad de la información certificado tiene hecha la mayor parte del trabajo: análisis de riesgos, política de seguridad, gestión de incidentes, continuidad de negocio y seguridad de proveedores son requisitos comunes.

Para el desarrollo en particular, los controles técnicos de la ISO 27001 aplicados al desarrollo seguro cubren prácticamente punto por punto lo que exige NIS2 en materia de ciclo de vida del software. Y si trabajas con el sector público, el Esquema Nacional de Seguridad añade su propia capa; hemos detallado en otro artículo las diferencias y sinergias entre el ENS y la ISO 27001, porque certificar las dos por separado cuando comparten el 70% de los controles es tirar presupuesto.

La recomendación práctica: construir un solo sistema de gestión y mapear sus controles contra cada marco, en lugar de abrir un proyecto independiente por cada norma que aparece. El coste de mantenimiento de tres sistemas paralelos es lo que acaba haciendo que ninguno se mantenga.

Sanciones y responsabilidad

Las multas del RGPD pueden alcanzar los 20 millones de euros o el 4% de la facturación global. NIS2 añade multas de hasta 10 millones de euros y responsabilidad personal de los directivos. No es un tema que pueda ignorarse: las autoridades están siendo cada vez más activas en las inspecciones y sanciones, especialmente tras brechas de datos.

Las cifras, con el detalle que importa

Conviene precisar los importes de NIS2, porque el titular de los diez millones se queda corto o largo según el caso. La directiva fija dos tramos en función de la categoría de la entidad, y en ambos se aplica la cantidad que resulte mayor:

• Entidades esenciales: hasta 10 millones de euros o el 2% de la facturación mundial total anual.
• Entidades importantes: hasta 7 millones de euros o el 1,4% de la facturación mundial total anual.

El detalle relevante es que el porcentaje se calcula sobre la facturación mundial del grupo, no sobre la actividad europea ni sobre la de la filial afectada. Para un grupo grande, el 2% supera con holgura los diez millones.

La responsabilidad personal de los directivos

Es la novedad que cambia la conversación en los comités de dirección. NIS2 atribuye a los órganos de dirección la obligación de aprobar las medidas de gestión de riesgos, supervisar su aplicación y formarse en la materia, y prevé que puedan ser considerados responsables del incumplimiento. Entre las medidas contempladas figura la posibilidad de suspender temporalmente a una persona del ejercicio de funciones directivas en la entidad.

En la práctica esto significa que la seguridad deja de poder delegarse por completo en el departamento técnico y presentarse como un gasto discutible. Para quien dirige un equipo de desarrollo, es también un argumento útil: las tareas de seguridad que llevan tres trimestres al final del backlog tienen ahora un interlocutor con responsabilidad directa en que se hagan.

Errores frecuentes que vemos en auditoría

Al revisar plataformas de clientes, los mismos fallos se repiten con una regularidad llamativa:

• El banner de cookies que no bloquea nada. Se muestra el aviso, pero los scripts de analítica y los píxeles de terceros ya se han cargado antes de que el usuario decida. Es el incumplimiento más fácil de detectar desde fuera y uno de los más sancionados.
• Confundir cifrado en tránsito con cifrado en reposo. Tener HTTPS no significa que la base de datos esté cifrada, ni que lo estén los backups o los volúmenes de almacenamiento.
• MFA solo para los usuarios finales. Los accesos realmente críticos —panel de hosting, repositorio, consola del proveedor cloud, acceso SSH— suelen ser los que siguen con contraseña simple y compartida.
• Plan de respuesta a incidentes que nadie ha leído. Un documento aprobado hace dos años, con teléfonos de personas que ya no trabajan allí, no es un plan. Una prueba anual de media hora basta para mantenerlo vivo.
• Proveedores sin contrato de encargado de tratamiento. Especialmente las herramientas que entran por la puerta de atrás: una extensión de analítica, un chat de soporte, un servicio de IA al que se le pegan conversaciones de clientes.
• Datos de producción en el portátil de alguien. La exportación que se hizo para depurar un problema y se quedó en la carpeta de descargas.

Preguntas frecuentes

¿Me aplica NIS2 si tengo una empresa de 20 personas?

Como sujeto obligado, con carácter general no: el umbral está en 50 empleados o 10 millones de facturación dentro de uno de los sectores cubiertos. Hay excepciones para proveedores críticos concretos, como registros de dominios o prestadores cualificados de servicios de confianza. Ahora bien, como proveedor de una entidad obligada, los requisitos te llegarán por contrato.

Si España aún no ha transpuesto NIS2, ¿puedo esperar?

Puedes esperar al régimen sancionador, pero no a los requisitos técnicos. Implantar gestión de accesos, trazabilidad, gestión de vulnerabilidades y capacidad de respuesta lleva meses. El plazo de adaptación que fije la ley empezará a contar desde su publicación, no desde que tu equipo se organice.

¿El CRA aplica a una aplicación web a medida para un solo cliente?

El reglamento se dirige a productos con elementos digitales comercializados en el mercado de la Unión. Un desarrollo a medida para un único cliente queda en una zona distinta a la de un producto distribuido, pero el servicio SaaS multicliente y los componentes que se publican sí entran de lleno. La recomendación es revisar caso por caso el modelo de comercialización antes de diciembre de 2027.

¿Certificarme en ISO 27001 me hace cumplir NIS2 automáticamente?

No automáticamente, pero cubre la mayor parte del camino. La ISO 27001 aporta el sistema de gestión y buena parte de los controles; lo que hay que añadir son las obligaciones específicas de notificación en plazo y los requisitos de gobernanza y formación del órgano de dirección.

¿Qué hago primero si no tengo nada?

Un inventario: qué sistemas hay, qué datos personales tratan, quién accede a ellos y qué proveedores intervienen. Sin ese mapa, cualquier medida posterior se aplica a ciegas. A partir de ahí, accesos y copias de seguridad, que son las dos que más riesgo quitan por menos esfuerzo. En seguridad informática para pymes desde cero desarrollamos ese recorrido paso a paso, y si lo que buscas es cobertura económica del riesgo residual, conviene entender antes qué cubre realmente un ciberseguro.

Conclusión

RGPD, NIS2 y CRA no son tres proyectos separados, sino tres exigencias que apuntan al mismo sitio: que el software se diseñe sabiendo qué datos trata, quién accede a ellos y qué se hace cuando algo falla. Quien tenga resuelto el inventario de datos, el control de accesos, la trazabilidad y la gestión de vulnerabilidades cumple la mayor parte de las tres a la vez.

El calendario, además, ya no permite demasiada planificación a largo plazo: la notificación de vulnerabilidades del CRA es exigible desde septiembre de 2026, la transposición española de NIS2 puede publicarse en cualquier momento y el RGPD lleva aplicándose ocho años. La diferencia entre las empresas que lo llevarán bien y las que no pasa por haber empezado antes de que llegara la carta, el cuestionario del cliente o el incidente.