La Directiva NIS2 en España: guía completa de ciberseguridad para empresas y PYMEs ante las inspecciones de 2026

5 de marzo de 2023: el día que un hospital se quedó a oscuras

La mañana del domingo 5 de marzo de 2023, los sistemas informáticos del Hospital Clinic de Barcelona dejaron de responder. No fue un apagón eléctrico ni un fallo de hardware. Fue un ataque de ransomware ejecutado por RansomHouse, un grupo de ciberdelincuentes que operó desde fuera de las fronteras españolas y que, en cuestión de horas, cifró los servidores del hospital, paralizó los servicios de urgencias, el laboratorio clínico y la farmacia, y robó 4,5 terabytes de datos de pacientes, profesionales y proveedores. Los centros de atención primaria vinculados al hospital —Casanova, Borrell y Les Corts— quedaron operando sin sistemas informáticos, atendiendo emergencias con lápiz y papel como si la medicina digital nunca hubiera existido.

Los atacantes exigieron un rescate de 4,5 millones de dólares. La Generalitat de Catalunya respondió con una frase que se convirtió en titular de todos los medios: «No se negociará, no se pagará ni un céntimo». RansomHouse cumplió su amenaza. El 30 de marzo inició la publicación de los datos robados en la dark web. En los meses siguientes completó la publicación de la totalidad de los 4,5 terabytes —historiales clínicos, datos personales de empleados, información financiera de proveedores— quedó expuesta y accesible para cualquiera con los conocimientos mínimos para navegar la web oscura. La Autoritat Catalana de Proteccio de Dades abrió expediente investigador contra el hospital para determinar si las medidas de seguridad implementadas habían sido suficientes.

El caso del Hospital Clinic no fue un incidente aislado. Fue el presagio de lo que vendría. En 2024, España vivió una avalancha de ciberataques sin precedentes: Iberdrola sufrió una brecha que comprometió los datos de 850.000 clientes, el Banco Santander reportó accesos no autorizados a bases de datos de clientes en España, Chile y Uruguay, Telefónica investigó el robo de 2,6 millones de registros, la DGT fue atacada, y Air Europa —que en octubre de 2023 había sufrido una intrusión que expuso números completos de tarjetas de crédito, códigos CVV y fechas de caducidad de sus clientes— ya acumulaba su segunda brecha grave en cinco años.

INCIBE —el Instituto Nacional de Ciberseguridad— gestionó 97.348 incidentes de ciberseguridad en 2024, un 16,6% más que el año anterior. En 2025, la cifra escaló a 122.223 incidentes, un aumento del 26%. Y el dato más revelador de todos: más del 70% de los ciberataques se dirigen contra pymes, y el 60% de las que sufren un incidente grave cierran en los seis meses siguientes.

Europa decidió que esto no podía continuar. La respuesta fue la Directiva NIS2 —formalmente, la Directiva (UE) 2022/2555—, la legislación de ciberseguridad más ambiciosa jamás aprobada por la Unión Europea. Y en 2026, sus efectos empiezan a ser tangibles: las inspecciones comienzan, las sanciones se activan y los directivos de las empresas descubren que la ciberseguridad ya no es un problema exclusivo del departamento de IT. Es un problema personal. Literalmente.

Este artículo es una guía exhaustiva sobre la Directiva NIS2 y su impacto en las empresas españolas. Qué obliga a hacer, a quién afecta, qué sanciones impone, cómo interactúa con el RGPD y con DORA, y —sobre todo— qué pasos concretos debe dar una pyme española para cumplir la normativa antes de que las inspecciones lleguen a su puerta.

Qué es la Directiva NIS2 y por qué existe

El fracaso relativo de NIS1

Para entender NIS2 hay que empezar por su predecesora. La Directiva NIS original —Directiva (UE) 2016/1148, conocida como NIS1— fue el primer intento de la Unión Europea de establecer un marco común de ciberseguridad. Entró en vigor en agosto de 2016 y los Estados miembros debían transponerla antes de mayo de 2018. España lo hizo a través del Real Decreto-ley 12/2018, de 7 de septiembre, de seguridad de las redes y sistemas de información.

NIS1 fue un paso importante, pero insuficiente. Su aplicación reveló tres problemas estructurales que la hacian inadecuada para el panorama de amenazas de la decada de 2020.

Fragmentación entre Estados miembros. NIS1 dejaba una amplia discrecionalidad a cada país para determinar qué entidades estaban en su ámbito de aplicación. El resultado fue una aplicación desigual: lo que en un país se consideraba operador de servicio esencial, en otro no lo era. Las empresas que operaban en varios Estados miembros se enfrentaban a un mosaico normativo incoherente que dificultaba —y encarecía— el cumplimiento.

Alcance limitado. NIS1 se centraba en un número reducido de sectores —energía, transporte, banca, salud, suministro de agua e infraestructuras digitales— y solo cubría a los operadores de servicios esenciales y a ciertos proveedores de servicios digitales. Sectores críticos como la gestión de residuos, la industria alimentaria, la fabricación de productos sanitarios o la administración pública quedaban fuera.

Medidas vagas y sanciones débiles. NIS1 exigía que las entidades adoptaran medidas «adecuadas y proporcionadas» para gestionar los riesgos de ciberseguridad, pero no definía esas medidas con especificidad. Las sanciones variaban enormemente entre países y, en muchos casos, eran tan bajas que las empresas preferían asumir el riesgo de una multa antes que invertir en ciberseguridad.

La génesis de NIS2: una respuesta al mundo post-pandemia

La pandemia de COVID-19 aceleró la digitalización de la economía europea a un ritmo que nadie había previsto. El teletrabajo masivo, la explosión del comercio electrónico, la digitalización de la sanidad y la dependencia creciente de servicios en la nube crearon una superficie de ataque inmensamente mayor. Los ciberdelincuentes lo aprovecharon: los ataques de ransomware se multiplicaron exponencialmente, los ataques a cadenas de suministro —como el devastador incidente de SolarWinds en 2020— demostraron que un solo proveedor comprometido podía poner en jaque a miles de organizaciones, y los ataques a infraestructuras críticas dejaron de ser una amenaza teórica para convertirse en una realidad cotidiana.

La Comisión Europea presentó su propuesta de revisión en diciembre de 2020. Tras dos años de negociaciones, la Directiva (UE) 2022/2555 —NIS2— fue publicada en el Diario Oficial de la Unión Europea el 27 de diciembre de 2022 y entró en vigor el 16 de enero de 2023. Los Estados miembros tenían hasta el 17 de octubre de 2024 para transponerla a su derecho nacional. NIS2 derogó la directiva original a partir del 18 de octubre de 2024.

Los cambios fundamentales de NIS2 respecto a NIS1

NIS2 no es una actualización incremental. Es una refundación completa del marco europeo de ciberseguridad. Los cambios pueden resumirse en seis ejes:

Primero, una expansión drástica del ámbito de aplicación. De unos pocos miles de entidades en toda la UE, NIS2 pasa a cubrir a decenas de miles. Se amplía a 18 sectores —frente a los 7 originales— y se introduce un criterio de tamaño armonizado que elimina la discrecionalidad nacional.

Segundo, medidas de seguridad concretas y medibles. El artículo 21 establece diez medidas mínimas obligatorias que toda entidad debe implementar, desde el análisis de riesgos hasta la autenticación multifactor.

Tercero, un régimen de notificación de incidentes estricto. La cascada de 24 horas, 72 horas y un mes deja poco margen para la improvisación.

Cuarto, la seguridad de la cadena de suministro como obligación explícita. Las empresas ya no pueden limitarse a proteger su propio perímetro: deben evaluar y gestionar los riesgos de sus proveedores.

Quinto, sanciones disuasorias. Multas de hasta 10 millones de euros o el 2% de la facturación global, alineadas con el modelo del RGPD.

Sexto —y este es el cambio más revolucionario— la responsabilidad personal de los directivos. Los consejos de administración y los CEO son directamente responsables del cumplimiento. Pueden ser sancionados personalmente e incluso inhabilitados temporalmente si se demuestra negligencia.

La transposición en España: una carrera contra el reloj

El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad

La fecha límite para transponer NIS2 era el 17 de octubre de 2024. España no cumplió ese plazo. Tampoco fue un caso aislado: la mayoría de los Estados miembros incumplieron la fecha, y el 7 de mayo de 2025 la Comisión Europea envió un dictamen motivado a 19 países —incluida España— por no haber notificado la transposición completa, amenazando con llevar el asunto ante el Tribunal de Justicia de la Unión Europea.

El Consejo de Ministros aprobó el Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad el 14 de enero de 2025. Este texto es el vehículo legislativo que transpone NIS2 al ordenamiento jurídico español. El Gobierno le otorgó tramitación de urgencia para acelerar su adopción. Sin embargo, a fecha de marzo de 2026, la ley aún no ha sido publicada en el Boletín Oficial del Estado (BOE). El proyecto legislativo se encuentra en tramitación parlamentaria, con previsiones de aprobación definitiva a lo largo de 2026.

Ahora bien, que la ley nacional no esté formalmente en vigor no significa que las empresas puedan relajarse. La Directiva NIS2, como toda directiva europea, establece obligaciones que los Estados miembros deben transponer, pero sus principios y umbrales ya están definidos y son conocidos. Las empresas que esperen a la publicación en el BOE para empezar a cumplir llegarán tarde. Y hay algo más: el efecto directo de las directivas europeas no transpuestas en plazo es un principio bien establecido del Derecho de la UE. Cuando un Estado miembro incumple el plazo de transposición, las disposiciones de la directiva que sean suficientemente claras, precisas e incondicionales pueden invocarse directamente ante los tribunales nacionales.

La arquitectura institucional: quién supervisa qué

El anteproyecto español establece una arquitectura institucional que distribuye las responsabilidades de supervisión entre varios organismos. Entender esta arquitectura es esencial para saber a quién debe notificar una empresa en caso de incidente y quién tiene potestad para inspeccionarla y sancionarla.

Centro Nacional de Ciberseguridad (CNCS). Es la pieza central de la nueva arquitectura. Adscrito a la Presidencia del Gobierno, tendrá funciones de dirección, coordinación y promoción de las políticas de protección digital a nivel nacional. Actuará como punto de contacto único con las instituciones de la UE y coordinará a las autoridades sectoriales, al CCN-CERT y al INCIBE-CERT.

INCIBE-CERT. Dependiente del Instituto Nacional de Ciberseguridad, adscrito al Ministerio de Transformación Digital, es el CSIRT —Computer Security Incident Response Team— de referencia para el sector privado y los ciudadanos. Si una empresa privada sufre un incidente de ciberseguridad, INCIBE-CERT es el equipo al que debe notificar y del que recibirá apoyo técnico.

CCN-CERT. Dependiente del Centro Criptológico Nacional, integrado en el Centro Nacional de Inteligencia (CNI) y adscrito al Ministerio de Defensa, es el CSIRT de referencia para el sector público. Ejerce la coordinación nacional de la respuesta técnica de los CSIRT de las administraciones públicas y la función de enlace para la cooperación transfronteriza.

Mando Conjunto del Ciberespacio (MCCE). Es el CSIRT de referencia para las Fuerzas Armadas.

Autoridades sectoriales. Cada sector crítico tiene su propia autoridad competente —la CNMC para energía y telecomunicaciones, el Banco de España para el sector bancario, la CNMV para mercados financieros, el Ministerio de Sanidad para el sector sanitario, etc.— que supervisa el cumplimiento de las obligaciones específicas de su ámbito.

«La ciberseguridad es una responsabilidad compartida. El Centro Nacional de Ciberseguridad coordinará, pero la supervisión efectiva corresponde a las autoridades sectoriales, que conocen las particularidades de cada industria.» — Exposición de motivos del Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad

A quién afecta: entidades esenciales, entidades importantes y el efecto cascada

La regla del tamaño: el umbral que define el alcance

NIS2 introduce un criterio de tamaño armonizado que elimina la discrecionalidad que plagaba NIS1. La regla es relativamente sencilla:

Están en el ámbito de NIS2 las empresas que superen el umbral de mediana empresa, es decir, aquellas que empleen a más de 50 personas o tengan un volumen de negocios anual o balance general anual superior a 10 millones de euros, y que operen en alguno de los 18 sectores cubiertos.

Las grandes empresas —250 o más empleados, o más de 50 millones de euros de facturación— que operen en sectores de alta criticidad se clasifican como entidades esenciales. Las medianas empresas —entre 50 y 249 empleados, o entre 10 y 50 millones de facturación— y las que operan en sectores de «otra criticidad» se clasifican generalmente como entidades importantes.

Existen excepciones relevantes. Algunas entidades están incluidas independientemente de su tamaño: los proveedores de servicios de confianza (trust services), los proveedores de servicios DNS, los registros de nombres de dominio de primer nivel (TLD), los proveedores de redes públicas de comunicaciones electrónicas, y las entidades de la administración pública a nivel central y regional. Los Estados miembros también pueden incluir entidades más pequeñas si presentan un perfil de riesgo elevado.

Los 18 sectores: radiografía completa

NIS2 divide los 18 sectores en dos categorías definidas en sus Anexos I y II. La distinción no es meramente taxonómica: determina el régimen de supervisión y las sanciones aplicables.

Anexo I — Sectores de Alta Criticidad (entidades esenciales):

Sector	Subsectores principales	Ejemplos en España
Energía	Electricidad, calefacción y refrigeración urbana, petróleo, gas, hidrógeno	Iberdrola, Endesa, Repsol, Naturgy, Red Eléctrica
Transporte	Aereo, ferroviario, marítimo, por carretera	Renfe, Aena, Navantia, empresas de transporte urbano
Banca	Entidades de crédito	Santander, BBVA, CaixaBank, Sabadell
Infraestructuras de los mercados financieros	Centros de negociación, contrapartes centrales	BME (Bolsas y Mercados Españoles), Iberclear
Sector sanitario	Prestadores de asistencia sanitaria, laboratorios de referencia, fabricantes de productos sanitarios críticos, I+D farmacéutico	Hospitales públicos, Grifols, Almirall, laboratorios de referencia del SNS
Agua potable	Suministradores y distribuidores de agua potable	Canal de Isabel II, Aigues de Barcelona, EMASA
Aguas residuales	Empresas de recogida, eliminación o tratamiento de aguas residuales	Depuradoras municipales, EDAR
Infraestructura digital	Puntos de intercambio de internet, DNS, TLD, servicios de computación en nube, centros de datos, redes de distribución de contenidos, proveedores de servicios de confianza	Centros de datos de Interxion (España), proveedores cloud españoles, Camerfirma
Gestión de servicios TIC (B2B)	Proveedores de servicios gestionados y de servicios de seguridad gestionados	Empresas de outsourcing IT, MSSPs españoles
Administración pública	Entidades de la administración pública central y regional	Ministerios, comunidades autónomas, diputaciones
Espacio	Operadores de infraestructuras terrestres de apoyo a servicios espaciales	Centros del INTA, estaciones de seguimiento de la ESA en España

Anexo II — Otros Sectores Criticos (entidades importantes):

Sector	Subsectores principales	Ejemplos en España
Servicios postales y de mensajería	Proveedores de servicios postales y de paquetería	Correos, SEUR, MRW, GLS Spain
Gestión de residuos	Empresas de recogida, tratamiento y reciclaje de residuos	Urbaser, FCC Medio Ambiente, Ecoembes
Fabricación, producción y distribución de sustancias químicas	Fabricantes y distribuidores de sustancias y mezclas químicas	Industria petroquímica de Tarragona, CEPSA Química
Producción, transformación y distribución de alimentos	Empresas alimentarias dedicadas a la distribución mayorista, producción industrial o transformación	Mercadona (logística), Ebro Foods, Grupo SOS, cooperativas agroalimentarias
Fabricación	Productos sanitarios, productos informáticos y electrónicos, maquinaria y equipo, vehículos de motor, material de transporte	SEAT/CUPRA, Gestamp, fabricantes de dispositivos médicos, plantas de componentes electrónicos
Proveedores digitales	Mercados en línea, motores de búsqueda, plataformas de redes sociales	Empresas con operaciones significativas en España: Wallapop, Idealista
Investigación	Organismos de investigación	CSIC, universidades públicas con actividad investigadora significativa

Entidades esenciales vs. entidades importantes: las diferencias que importan

Ambas categorías comparten la inmensa mayoría de las obligaciones sustantivas —las diez medidas de seguridad del artículo 21, los requisitos de notificación de incidentes del artículo 23, las obligaciones de gobernanza del artículo 20—. La diferencia principal radica en el régimen de supervisión y en las sanciones.

Aspecto	Entidades esenciales	Entidades importantes
Supervisión	Proactiva, ex ante: inspecciones regulares programadas, auditorías de seguridad periódicas	Reactiva, ex post: supervisión solo cuando hay indicios de incumplimiento o tras un incidente
Sanción máxima	10.000.000 € o 2% de la facturación global anual (lo que sea mayor)	7.000.000 € o 1,4% de la facturación global anual (lo que sea mayor)
Inhabilitación de directivos	Sí, posibilidad de suspensión temporal de funciones directivas	No prevista expresamente
Auditorias obligatorias	Periodicas y sistematicas	Bajo demanda o tras incidente

La distinción entre supervisión proactiva y reactiva es fundamental. Una entidad esencial debe asumir que será inspeccionada —no si, sino cuándo—. Una entidad importante puede no ser inspeccionada nunca si no hay un incidente o una denuncia, pero eso no la exime de cumplir todas las obligaciones. Si un incidente revela deficiencias, las sanciones se aplicarán igualmente.

El efecto cascada: por qué las pymes que no están en el ámbito directo también se ven afectadas

Aquí es donde NIS2 se convierte en un tsunami normativo que va mucho más allá de las entidades directamente reguladas. El artículo 21.2.d) obliga a las entidades esenciales e importantes a gestionar la seguridad de su cadena de suministro, incluyendo «los aspectos relativos a la seguridad de las relaciones entre cada entidad y sus proveedores o prestadores de servicios directos».

En la práctica, esto significa que una pyme que desarrolle software para un hospital, que suministre componentes electrónicos a un fabricante de automóviles, que preste servicios de limpieza industrial a una planta química, o que gestione el mantenimiento informático de una administración pública, se verá afectada indirectamente por NIS2, aunque no alcance el umbral de 50 empleados ni los 10 millones de facturación.

El mecanismo es contractual. Las entidades reguladas por NIS2 empezarán a incluir cláusulas de ciberseguridad en sus contratos con proveedores. Exigirán certificaciones, auditorías, cuestionarios de madurez en ciberseguridad y compromisos contractuales de notificación de incidentes. Un proveedor que no pueda cumplir esas exigencias perderá contratos. No será la autoridad nacional quien lo supervise directamente, sino su propio cliente.

Las empresas que forman parte habitual de la cadena de suministro de entidades reguladas empezarán a recibir cuestionarios de ciberseguridad de sus clientes, solicitudes de renegociación contractual y requisitos NIS2 detallados en los nuevos contratos. — DLA Piper, «NIS2 Directive Explained: Supply Chain Security», diciembre de 2025

Pensemos en una analogía. Cuando el RGPD obligó a los responsables del tratamiento a garantizar que sus encargados del tratamiento cumplian con la normativa de protección de datos, miles de pymes que nunca habían oido hablar del RGPD se encontraron firmando contratos de encargo de tratamiento y adaptando sus políticas de privacidad. Con NIS2 ocurrirá algo similar, pero en el ámbito de la ciberseguridad. El «efecto cascada» multiplicará el impacto de la directiva mucho más allá de su ámbito de aplicación formal.

El caso de Iberdrola en mayo de 2024 ilustra perfectamente el riesgo de la cadena de suministro. Los atacantes no vulneraron los sistemas de Iberdrola directamente: explotaron una vulnerabilidad en los sistemas de un proveedor externo. La gran empresa sufrió las consecuencias —850.000 clientes afectados, daño reputacional, posible expediente sancionador—, pero el origen del problema estaba en un eslabón de su cadena de suministro. Bajo NIS2, Iberdrola habría tenido la obligación no solo de proteger sus propios sistemas, sino de haber evaluado y supervisado la seguridad de ese proveedor. Y el proveedor, a su vez, habría estado contractualmente obligado a mantener un nivel de seguridad adecuado.

Para las pymes que son proveedoras de grandes empresas, la recomendación práctica es clara: no esperar a que el cliente les exija cumplimiento. Anticiparse, implementar las medidas básicas de ciberseguridad, documentar las políticas y procedimientos, y estar preparados para responder a los cuestionarios de madurez en ciberseguridad que, inevitablemente, empezarán a llegar. Las empresas que demuestren proactividad en su postura de seguridad tendrán una ventaja competitiva significativa frente a las que reaccionen solo cuando les obliguen.

Las diez medidas de seguridad: el artículo 21 al detalle

El artículo 21 de NIS2 es el núcleo operativo de la directiva. Establece diez medidas mínimas de gestión de riesgos de ciberseguridad que toda entidad esencial e importante debe implementar. No son orientaciones ni recomendaciones: son obligaciones legales cuyo incumplimiento puede acarrear las sanciones previstas en la directiva. Vamos a examinar cada una con el detalle que merece.

(a) Políticas de análisis de riesgos y seguridad de los sistemas de información

Esta es la medida fundacional sobre la que se construyen todas las demas. La entidad debe contar con una política formal de seguridad de la información aprobada por la dirección, que defina el enfoque de la organización para la gestión de riesgos de ciberseguridad. Esta política debe basarse en un análisis de riesgos periódico que identifique las amenazas, evalúa las vulnerabilidades y determine las medidas de mitigación necesarias.

No se trata de rellenar un formulario una vez y archivarlo. El análisis de riesgos debe ser un proceso continuo que se actualice ante cambios significativos en la infraestructura, en el entorno de amenazas o en la organización. ENISA —la Agencia de la Unión Europea para la Ciberseguridad— recomienda explícitamente el uso de marcos como ISO/IEC 27001:2022, ISO/IEC 27005 o el NIST Cybersecurity Framework 2.0 como referencia, aunque no impone ninguno de forma obligatoria. El Reglamento de Ejecución (UE) 2024/2690, de 17 de octubre de 2024, concreta los requisitos técnicos para determinados tipos de entidades.

(b) Gestión de incidentes

La entidad debe disponer de procedimientos documentados para la detección, análisis, contención, erradicación y recuperación de incidentes de ciberseguridad. No basta con tener un antivirus y esperar lo mejor. Se necesita un plan de respuesta a incidentes que defina roles y responsabilidades, canales de comunicación, procedimientos de escalado, criterios para clasificar la gravedad de los incidentes y protocolos de preservación de evidencias para facilitar la investigación forense posterior.

Este requisito está directamente conectado con las obligaciones de notificación del artículo 23, que analizaremos en la siguiente sección. Si una empresa no tiene procedimientos de gestión de incidentes, difícilmente podrá cumplir los plazos de notificación de 24 y 72 horas.

(c) Continuidad de negocio, gestión de copias de seguridad, recuperación ante desastres y gestión de crisis

Esta medida exige que la entidad planifique cómo va a seguir operando si sus sistemas sufren una interrupción grave. Incluye tres componentes principales: un plan de continuidad de negocio (BCP, Business Continuity Plan) que identifique los procesos críticos y las alternativas para mantenerlos operativos, una política de copias de seguridad (backups) que garantice la disponibilidad de los datos incluso si los sistemas primarios quedan comprometidos, y un plan de recuperación ante desastres (DRP, Disaster Recovery Plan) que defina cómo restaurar los sistemas a su estado operativo normal.

El caso del Hospital Clinic es un ejemplo perfecto de por qué esta medida es crítica. Cuando el ransomware cifró los servidores del hospital, la capacidad de continuar prestando servicios de urgencia dependió de la existencia —o no— de copias de seguridad aisladas de la red principal y de procedimientos alternativos para los procesos más críticos.

(d) Seguridad de la cadena de suministro

Ya hemos analizado el impacto indirecto de este requisito. A nivel operativo, la entidad debe evaluar los riesgos de ciberseguridad asociados a sus proveedores directos y prestadores de servicios, incorporar requisitos de seguridad en los contratos con proveedores, y supervisar de forma continua el cumplimiento de esos requisitos. Esto incluye evaluar las prácticas de desarrollo de software de los proveedores, sus políticas de gestión de vulnerabilidades, y la calidad general de sus medidas de ciberseguridad.

(e) Seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información, incluida la gestión y divulgación de vulnerabilidades

Esta medida aborda la seguridad del ciclo de vida completo de los sistemas de información. Desde el momento en que se adquiere o desarrolla un nuevo sistema, pasando por su despliegue, su mantenimiento y su eventual retirada. Incluye la obligación de implementar políticas de gestión de vulnerabilidades —parcheo sistemático, escaneo de vulnerabilidades, priorizado de remediation— y de divulgación coordinada de vulnerabilidades (coordinated vulnerability disclosure).

(f) Políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos de ciberseguridad

No basta con implementar medidas: hay que verificar que funcionan. La directiva exige que las entidades establezcan mecanismos para medir y evaluar la eficacia de sus controles de seguridad. Esto puede incluir auditorías internas, pruebas de penetración (pentesting), ejercicios de simulación de ataques (red teaming), y métricas de rendimiento de los controles de seguridad. La clave es que la evaluación sea periódica, documentada y que sus resultados se utilicen para mejorar continuamente las medidas de seguridad.

(g) Prácticas básicas de ciber higiene y formación en ciberseguridad

La inmensa mayoría de los ciberataques exitosos explotan el factor humano: un empleado que hace clic en un enlace de phishing, que usa una contraseña débil, que conecta un USB desconocido al equipo corporativo. Esta medida exige que las entidades implementen programas de concienciación y formación en ciberseguridad para todos los empleados, incluidos los directivos. Las «prácticas básicas de ciber higiene» incluyen la gestión adecuada de contraseñas, la actualización regular del software, el uso seguro del correo electrónico, y la capacidad de identificar intentos de ingeniería social.

El artículo 20 de la directiva es explícito: los miembros de los órganos de dirección deben recibir formación específica para adquirir «conocimientos y competencias suficientes que les permitan identificar riesgos y evaluar las prácticas de gestión de riesgos de ciberseguridad y su incidencia en los servicios prestados por la entidad».

(h) Políticas y procedimientos relativos al uso de criptografía y, en su caso, cifrado

La entidad debe definir cuándo y cómo utiliza el cifrado para proteger la confidencialidad e integridad de los datos. Esto incluye políticas sobre el cifrado de datos en reposo (at rest) y en tránsito (in transit), la gestión de claves criptográficas, los algoritmos y protocolos aceptables, y los procedimientos para la rotación y revocación de claves. La medida no impone el uso de cifrado en todos los casos, pero sí que la decisión de cifrar o no cifrar sea consciente, documentada y basada en el análisis de riesgos.

(i) Seguridad de los recursos humanos, políticas de control de acceso y gestión de activos

Esta medida abarca tres áreas interrelacionadas. La seguridad de los recursos humanos incluye verificaciones previas a la contratación, cláusulas de confidencialidad, y procedimientos de desvinculación que garanticen la revocación de accesos cuando un empleado deja la organización. Las políticas de control de acceso deben seguir el principio de mínimo privilegio: cada usuario solo debe tener acceso a los recursos estrictamente necesarios para desempeñar sus funciones. La gestión de activos exige un inventario actualizado de todos los activos de información —hardware, software, datos, servicios— y la asignación de un responsable para cada activo.

(j) Uso de autenticación multifactor o autenticación continua, comunicaciones seguras de voz, video y texto, y sistemas de comunicación de emergencia seguros

La última medida del catálogo es quizá la más concreta y la más fácil de verificar en una inspección. La autenticación multifactor (MFA, Multi-Factor Authentication) ya no es una buena práctica opcional: es una obligación legal. El acceso a sistemas críticos debe requerir al menos dos factores de autenticación independientes —algo que el usuario sabe (contraseña), algo que tiene (token, teléfono móvil) o algo que es (biometría)—. La medida también exige comunicaciones internas seguras, lo que afecta a las herramientas de mensajería, videoconferencia y correo electrónico utilizadas por la organización.

Notificación de incidentes: la cascada de 24-72-30

Qué es un «incidente significativo»

El artículo 23 de NIS2 establece las obligaciones de notificación de incidentes. Pero no todos los incidentes deben notificarse: solo los incidentes significativos. Un incidente se considera significativo cuando cumple al menos uno de estos dos criterios:

Primero, que haya causado o pueda causar una perturbación operativa grave de los servicios o pérdidas económicas significativas para la entidad afectada.

Segundo, que haya afectado o pueda afectar a otras personas físicas o jurídicas causándoles perjuicios materiales o inmateriales considerables.

La definición es deliberadamente amplia. Un ataque de ransomware que cifre los servidores de producción es claramente un incidente significativo. Pero también puede serlo una brecha de datos que exponga información personal de clientes, un ataque de denegación de servicio (DDoS) que impida el acceso a servicios críticos durante un período prolongado, o un acceso no autorizado a sistemas internos aunque no se haya producido exfiltración de datos —si ese acceso podría haber causado daño significativo—.

Los tres informes obligatorios

Una vez detectado un incidente significativo, la entidad debe presentar tres informes sucesivos ante su CSIRT de referencia —INCIBE-CERT para el sector privado, CCN-CERT para el sector público— o ante la autoridad competente correspondiente:

1. Alerta temprana (early warning) — en un plazo máximo de 24 horas desde que la entidad tiene conocimiento del incidente. No se exige un análisis detallado en esta fase. El informe debe indicar si el incidente se sospecha que ha sido causado por actos ilicitos o malintencionados, y si podría tener impacto transfronterizo. El objetivo es que las autoridades puedan activar los mecanismos de alerta temprana y coordinar la respuesta si el incidente afecta a varios Estados miembros.

2. Notificación del incidente — en un plazo máximo de 72 horas desde el conocimiento del incidente. Este segundo informe actualiza la información de la alerta temprana y debe incluir una evaluación inicial del incidente: su gravedad, su impacto, y los indicadores de compromiso (indicators of compromise, IoC) disponibles. Es un informe intermedio que permite a las autoridades calibrar la magnitud del incidente.

3. Informe final — en un plazo máximo de un mes desde la presentación de la notificación del incidente. Este informe debe contener una descripción detallada del incidente, incluyendo su gravedad e impacto; el tipo de amenaza o causa raiz que probablemente lo originó; las medidas de mitigación aplicadas y en curso; y, en su caso, el impacto transfronterizo del incidente.

La presión del reloj: implicaciones prácticas del plazo de 24 horas

El plazo de 24 horas para la alerta temprana es enormemente exigente en la práctica. Pensemos en lo que implica: una empresa sufre un ciberataque a las 2 de la madrugada de un sábado. El equipo de IT detecta anomalías a las 6 de la mañana. A las 8, confirman que se trata de un incidente de seguridad. A partir de ese momento, tienen 24 horas para evaluar si el incidente es «significativo» y, si lo es, enviar la alerta temprana al CSIRT de referencia.

Para una gran empresa con un SOC (Security Operations Center) operativo 24/7, esto es un reto gestionable. Para una mediana empresa con un departamento de IT de cinco personas, ninguna de las cuales trabaja los fines de semana, es un reto considerable. Y para una pyme que subcontrata la gestión de IT a un proveedor externo, puede ser directamente inalcanzable si no se ha planificado con antelación.

La moraleja es clara: el cumplimiento del artículo 23 no se improvisa. Requiere tener definidos previamente los procedimientos de detección, clasificación y escalado de incidentes, los canales de comunicación con el CSIRT de referencia, las personas autorizadas para enviar las notificaciones, y las plantillas o herramientas para generar los informes en los plazos establecidos. Requiere, en definitiva, haber cumplido primero con las medidas (b) y (c) del artículo 21.

Comparación con el RGPD: notificaciones paralelas

Si un incidente de ciberseguridad implica también una brecha de datos personales —como ocurrió en el caso de Iberdrola, Air Europa o el Hospital Clinic—, la empresa tiene obligaciones de notificación paralelas:

Aspecto	NIS2 (Art. 23)	RGPD (Art. 33-34)
Destinatario	CSIRT de referencia (INCIBE-CERT / CCN-CERT) o autoridad competente	Autoridad de protección de datos (AEPD en España)
Plazo inicial	24 horas (alerta temprana)	72 horas (notificación a la autoridad)
Notificación a afectados	No exigida directamente (pero las autoridades pueden ordenarla)	Obligatoria si hay alto riesgo para los derechos y libertades
Criterio de activación	Incidente «significativo» (impacto operativo o económico)	Brecha de datos personales (riesgo para derechos y libertades)

Es perfectamente posible —y frecuente— que un mismo incidente active ambas obligaciones simultáneamente. Las empresas deben estar preparadas para gestionar las dos notificaciones en paralelo, lo que exige una coordinación interna eficiente entre los equipos de ciberseguridad, legal y protección de datos.

La responsabilidad personal de los directivos: el gran cambio cultural

El artículo 20: cuando la ciberseguridad deja de ser «un problema de IT»

Si hay un artículo de NIS2 que debería quitar el sueño a los directivos de empresas españolas, es el artículo 20. Su contenido merece ser citado textualmente:

«Los Estados miembros velarán por que los órganos de dirección de las entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad adoptadas por dichas entidades en cumplimiento del artículo 21, supervisen su aplicación y puedan ser considerados responsables de las infracciones cometidas por las entidades en relación con dicho artículo.» — Artículo 20.1, Directiva (UE) 2022/2555

Tres verbos clave: aprobar, supervisar, responder. Ya no basta con que el consejo de administración delegue la ciberseguridad en el CISO (Chief Information Security Officer) o en el director de IT y se desentienda. La directiva exige que los órganos de dirección participen activamente en la gobernanza de la ciberseguridad. Deben aprobar las políticas de seguridad, supervisar que se implementan correctamente, y serán personalmente responsables si no lo hacen.

La obligación de formación de los directivos

El artículo 20.2 añade una obligación adicional que resulta igualmente disruptiva:

«Los Estados miembros velarán por que los miembros de los órganos de dirección de las entidades esenciales e importantes estén obligados a asistir a formación, y alentarán a las entidades esenciales e importantes a ofrecer periódicamente formación análoga a sus empleados, a fin de que estos adquieran conocimientos y competencias suficientes que les permitan identificar riesgos y evaluar las prácticas de gestión de riesgos de ciberseguridad y su incidencia en los servicios prestados por la entidad.» — Artículo 20.2, Directiva (UE) 2022/2555

Esto no es una recomendación. Es una obligación legal. Los directivos —consejeros, administradores, directores generales— deben recibir formación en ciberseguridad. No necesitan convertirse en expertos técnicos, pero sí deben adquirir «conocimientos y competencias suficientes» para comprender los riesgos, evaluar las medidas de protección y tomar decisiones informadas.

Las consecuencias personales: inhabilitación y responsabilidad patrimonial

El artículo 32 de NIS2 otorga a las autoridades competentes la potestad de adoptar medidas de supervisión que pueden llegar hasta la suspensión temporal de personas en funciones directivas de entidades esenciales cuando se constate un incumplimiento grave y reiterado. Esta medida es extraordinariamente severa: un CEO puede ser temporalmente apartado de sus funciones por no haber garantizado el cumplimiento de NIS2.

Además, cuando se demuestre negligencia grave por parte de la dirección tras un incidente de ciberseguridad, los Estados miembros pueden prever la publicación de las identidades de las personas físicas y jurídicas responsables de la infracción. El daño reputacional de esa publicación puede ser, para muchos directivos, incluso más disuasorio que la multa económica.

España, en su anteproyecto de ley, contempla la posibilidad de sancionar personalmente a los directivos e incluso de inhabilitar temporalmente a quienes no supervisen el cumplimiento de las obligaciones de ciberseguridad de la empresa. Es un enfoque que sitúa a España entre los Estados miembros más estrictos en la transposición de este aspecto de la directiva.

El cambio cultural necesario: de la delegación al liderazgo

Para entender la magnitud de este cambio, pensemos en cómo funciona la ciberseguridad en la inmensa mayoría de las empresas españolas hoy. El consejo de administración o la dirección general ven la ciberseguridad como un coste operativo, un gasto de IT, algo que «los técnicos» gestionan. Las decisiones de inversión en seguridad se toman —si se toman— en el departamento de IT, con presupuestos limitados y poca visibilidad a nivel de dirección. Cuando hay que recortar gastos, la ciberseguridad es uno de los primeros candidatos.

NIS2 invierte esa dinámica. La ciberseguridad deja de ser un tema técnico delegable y se convierte en una responsabilidad de gobierno corporativo, al mismo nivel que la gestión financiera, el cumplimiento normativo o la prevención de riesgos laborales. El consejo de administración debe tener la ciberseguridad en su agenda, debe recibir informes periódicos sobre el estado de la seguridad, debe aprobar las políticas y presupuestos, y debe poder demostrar que lo ha hecho.

Es un cambio análogo al que el RGPD provocó en la protección de datos. Antes de 2018, la privacidad era «un tema de abogados». Después de las primeras multas millonarias, se convirtió en un tema de consejo de administración. NIS2 hará lo mismo con la ciberseguridad, pero con un añadido: la responsabilidad personal de los directivos.

Sanciones: las cifras que cambian el cálculo

El régimen sancionador de NIS2

El artículo 34 de NIS2 establece el marco general para la imposición de sanciones administrativas. Los importes son lo suficientemente elevados como para que ninguna empresa pueda considerar las multas como un «coste de hacer negocios»:

Tipo de entidad	Sanción máxima	Cálculo alternativo
Entidades esenciales	10.000.000 €	2% de la facturación global anual (lo que sea mayor)
Entidades importantes	7.000.000 €	1,4% de la facturación global anual (lo que sea mayor)

Estos son umbrales mínimos. Los Estados miembros pueden establecer sanciones superiores en sus legislaciones nacionales. Además de las multas, las autoridades pueden adoptar medidas no pecuniarias:

• Órdenes de cumplimiento: instrucciones vinculantes para que la entidad implemente determinadas medidas en un plazo específico.
• Órdenes de ejecución de auditorías de seguridad: la autoridad puede obligar a la entidad a contratar y pagar una auditoría independiente.
• Órdenes de notificación a los usuarios: si el incumplimiento pone en riesgo a los usuarios del servicio, la autoridad puede obligar a la entidad a informarles.
• Publicación de la sanción: la identidad de la entidad infractora y de las personas responsables puede hacerse pública.
• Suspensión temporal de actividades: en casos extremos, la autoridad puede ordenar la suspensión de la prestación de servicios.

Comparación con el RGPD: el efecto disuasorio multiplicado

La estructura sancionadora de NIS2 está claramente inspirada en el modelo del RGPD. Pero hay diferencias relevantes:

Aspecto	RGPD	NIS2
Sanción máxima (tipo más grave)	20.000.000 € o 4% facturación global	10.000.000 € o 2% facturación global
Responsabilidad personal directivos	No prevista expresamente	Sí, con posibilidad de inhabilitación
Supervisión proactiva	Limitada (actuación principalmente reactiva)	Sí, para entidades esenciales (inspecciones programadas)
Publicación identidad infractores	Sí, según el caso	Sí, prevista expresamente

Aunque las cifras del RGPD son superiores en términos absolutos, NIS2 introduce un elemento que el RGPD no contempla: la responsabilidad personal. Un director general puede ser multado por una infracción del RGPD como representante de la empresa, pero NIS2 va más allá y permite sancionar a las personas físicas que integran los órganos de dirección de forma individual, así como inhabilitar temporalmente a directivos de entidades esenciales.

El cálculo económico: cumplir vs. no cumplir

Para una pyme española, los números son elocuentes. Según datos de INCIBE y del sector asegurador, el coste medio de un ciberataque a una pyme española oscila entre 35.000 y 80.000 euros, con una tendencia al alza: el coste ha aumentado un 25% en los últimos años. Algunas estimaciones sitúan el coste medio en torno a los 200.000 euros cuando se incluyen las pérdidas indirectas —lucro cesante, daño reputacional, costes legales, gastos de recuperación—.

Frente a eso, el coste de implementar las medidas básicas de ciberseguridad exigidas por NIS2 —análisis de riesgos, políticas de seguridad, formación, MFA, backups, plan de respuesta a incidentes— es significativamente inferior al coste potencial de un incidente más la multa por incumplimiento. La inversión en ciberseguridad ya no es solo una decisión técnica prudente: es una decisión económica racional.

Pongamos un ejemplo concreto. Una pyme del sector alimentario con 80 empleados y 15 millones de facturación entra en el ámbito de NIS2 como entidad importante. La sanción máxima que podría recibir es de 7 millones de euros o el 1,4% de su facturación —210.000 euros—, lo que sea mayor. El coste de implementar un programa básico de cumplimiento NIS2 —análisis de riesgos, políticas documentadas, MFA, backups adecuados, formación, plan de respuesta a incidentes— puede oscilar entre 15.000 y 40.000 euros para una empresa de ese tamaño, dependiendo del estado de partida y de si se apoya en consultoría externa. Es una fracción del coste potencial de un solo incidente, y una fracción aún menor de la sanción potencial.

El cálculo se vuelve todavía más favorable si se tiene en cuenta el coste del seguro de ciberriesgos. Las aseguradoras están ajustando las primas al alza para las empresas que no demuestran un nivel adecuado de madurez en ciberseguridad. Algunas directamente rechazan la cobertura. Cumplir con NIS2 no solo reduce el riesgo de incidentes y sanciones: también puede reducir significativamente la prima del ciberseguro o, sencillamente, hacer posible la contratación de una póliza que de otro modo no estaría disponible.

El panorama real: ciberataques e incidentes en España

2024-2025: la avalancha

Los datos de INCIBE dibujan un panorama alarmante. En 2024, se gestionaron 97.348 incidentes de ciberseguridad, un 16,6% más que en 2023. De ellos, 65.808 (el 67,6%) afectaron a ciudadanos y 31.540 (el 32,4%) a empresas, incluyendo pymes, micropymes y autónomos. El servicio «Tu Ayuda en Ciberseguridad» atendió 98.546 consultas, un 21,8% más que el año anterior.

En 2025, la escalada continuo: 122.223 incidentes gestionados, un 26% más que en 2024. De ellos, 55.411 fueron incidentes de malware, 392 casos específicos de ransomware, y 45.445 de fraude online (un 19% más que el año anterior). Se registraron 25.133 reportes de phishing. Y un dato que debería preocupar a cualquier CISO: se identificaron 237.028 sistemas vulnerables en todo el territorio nacional. La Linea de Ayuda en Ciberseguridad 017 atendió 142.767 consultas, un 44,9% más que en 2024.

España registró un aumento del 116% en ataques de ransomware durante 2025. El país se ha convertido en uno de los principales objetivos de los ciberdelincuentes en Europa, en parte por su tejido empresarial dominado por pymes con recursos limitados de ciberseguridad, y en parte por la creciente digitalización de la economía y los servicios públicos.

Los grandes incidentes que marcaron la agenda

Hospital Clinic de Barcelona (marzo 2023). Ya lo hemos descrito en detalle. RansomHouse robó 4,5 TB de datos y paralizó urgencias, laboratorio y farmacia. Se exigió un rescate de 4,5 millones de dólares que no fue pagado. Todos los datos fueron publicados en la dark web.

Iberdrola (mayo 2024). Los atacantes accedieron a los sistemas entre el 5 y el 7 de mayo explotando una vulnerabilidad en los sistemas de un proveedor externo. Se comprometieron los datos de 850.000 clientes: nombres, apellidos, DNI y datos de contacto. Los datos aparecieron a la venta en foros de ciberdelincuencia.

Banco Santander (mayo 2024). La entidad reportó a la CNMV un «acceso no autorizado a una base de datos» que contenía información de clientes en España, Chile y Uruguay. El banco aseguro que no se vieron comprometidos datos transaccionales ni credenciales de acceso a la banca online, pero los datos personales de millones de clientes quedaron expuestos.

Telefónica (2024). La multinacional investigó el posible robó de datos de aproximadamente 120.000 usuarios y empleados, con hackers ofreciendo una base de datos de más de 2,6 millones de registros en foros de ciberdelincuencia.

Air Europa (octubre 2023). Los atacantes comprometieron el sistema de pasarela de pago de la aerolinea, accediendo a números completos de tarjetas de crédito, códigos CVV y fechas de caducidad. La aerolinea pidió a los clientes que cancelaran sus tarjetas. No fue su primer incidente: en 2018 había sufrido una brecha similar por la que la AEPD le impuso una multa de 600.000 euros en 2021, entre otros motivos por haber tardado 41 días en notificar a los afectados.

DGT, Decathlon, y otros (2024). La Dirección General de Tráfico sufrió un ciberataque que comprometió datos de conductores. Decathlon España y otros comercios fueron también objetivo de intrusiones. La ola de ataques de mayo-junio de 2024, que afectó simultáneamente a varias empresas del IBEX 35 y a organismos públicos, fue descrita por los expertos como sin precedentes en la historia de la ciberseguridad española.

Endesa (enero 2026). Un hackeo a la compañía eléctrica comprometió datos sensibles de clientes, incluyendo DNI y números de cuenta bancaria. El incidente demostró que ni siquiera las empresas del sector energético —que llevan años sujetas a regulación de ciberseguridad por su condición de operadores de infraestructuras críticas— son inmunes a los ataques.

La anatomía de un ataque: cómo se desarrolla un incidente típico

Para comprender por qué NIS2 exige las medidas que exige, es util entender cómo funciona un ciberataque típico contra una empresa española. El patron más común sigue una secuencia predecible, que los expertos denominan kill chain.

Fase 1: Reconocimiento. El atacante recopila información sobre la empresa objetivo: direcciones de correo electrónico de empleados (disponibles en LinkedIn, en la web corporativa, en filtraciones previas), tecnologías utilizadas (identificables a través de cabeceras HTTP, registros DNS, ofertas de empleo que mencionan tecnologías específicas), y relaciones con proveedores y clientes.

Fase 2: Acceso inicial. En el 80-90% de los casos, el vector de entrada es el correo electrónico: un phishing dirigido (spear phishing) que imita un mensaje de un proveedor, un cliente, una entidad bancaria o un organismo público. El empleado que hace clic en el enlace o abre el archivo adjunto proporciona inadvertidamente las credenciales de acceso al atacante, o ejecuta un malware que le da acceso al equipo.

Fase 3: Movimiento lateral. Una vez dentro, el atacante explora la red interna, busca credenciales con privilegios elevados —las del administrador de dominio, las del responsable de bases de datos—, y se desplaza lateralmente hacia los sistemas más valiosos. Esta fase puede durar días, semanas o incluso meses. El atacante opera con paciencia, evitando activar alarmas.

Fase 4: Exfiltración y cifrado. Cuando el atacante ha localizado los datos valiosos y ha obtenido acceso a los sistemas críticos, copia los datos fuera de la red de la empresa (exfiltración) y, en el caso del ransomware, cifra los servidores y estaciones de trabajo, dejando una nota de rescate.

Fase 5: Extorsión. El atacante exige un pago —habitualmente en criptomonedas— a cambio de la clave de descifrado y de la promesa de no publicar los datos robados. Si la empresa no paga, los datos se publican en la dark web, y en algunos casos se contacta directamente a los clientes afectados para aumentar la presión.

Cada una de las diez medidas del artículo 21 de NIS2 está diseñada para interrumpir esta cadena en alguno de sus eslabones. La formación en ciber higiene reduce la probabilidad de que un empleado caiga en un phishing (fase 2). La MFA impide que unas credenciales robadas den acceso al sistema (fase 2-3). La segmentación de red y el control de acceso dificultan el movimiento lateral (fase 3). El cifrado de datos en reposo reduce el valor de los datos exfiltrados (fase 4). Los backups aislados permiten la recuperación sin necesidad de pagar el rescate (fase 5). El plan de respuesta a incidentes permite detectar y contener el ataque antes de que se complete la cadena.

Por que las pymes son las más vulnerables

Las grandes empresas del IBEX 35 tienen recursos para absorber un ciberataque: equipos de respuesta, ciberseguros, departamentos legales especializados, y la capacidad de invertir millones en recuperación. Las pymes, no.

Los datos son contundentes: más del 70% de los ciberataques en España se dirigen contra pymes. Y el dato más devastador: el 60% de las pymes que sufren un ciberataque grave cierran en los seis meses siguientes. No cierran porque la multa sea insoportable. Cierran porque la interrupción de la actividad, la perdida de datos, el daño reputacional y los costes de recuperación agotan los recursos de empresas que, típicamente, operan con margenes estrechos y poca capacidad de endeudamiento.

La paradoja es que las pymes invierten proporcionalmente menos en ciberseguridad que las grandes empresas, precisamente porque perciben que «no son un objetivo». Pero los ciberdelincuentes las atacan precisamente porque saben que están menos protegidas. Un ataque de ransomware que sería un inconveniente para una gran corporación puede ser una sentencia de muerte para una pyme. NIS2, al elevar el nivel mínimo de seguridad, busca romper ese círculo vicioso.

Interacción con otras normativas: RGPD, DORA y el ecosistema regulador europeo

NIS2 y el RGPD: dos caras de la misma moneda

NIS2 y el RGPD (Reglamento General de Protección de Datos) abordan aspectos diferentes pero complementarios de la seguridad digital. El RGPD protege los datos personales y regula su tratamiento. NIS2 protege las redes y sistemas de información y regula su seguridad. Pero en la práctica, ambas normativas convergen constantemente: una brecha de datos personales suele ser consecuencia de un fallo de ciberseguridad, y un incidente de ciberseguridad frecuentemente implica datos personales.

Las empresas deben desarrollar una estrategia de cumplimiento integrada que aborde ambas normativas de forma coordinada. Las medidas técnicas del artículo 21 de NIS2 —cifrado, control de acceso, gestión de activos— sirven también para cumplir las medidas de seguridad del artículo 32 del RGPD. Los procedimientos de notificación de incidentes, aunqué tienen destinatarios y plazos diferentes, pueden basarse en un mismo proceso interno de detección y clasificación.

Pensemos en un ejemplo práctico. Iberdrola sufre una brecha en mayo de 2024 que expone datos personales de 850.000 clientes. Bajo el RGPD, debe notificar a la AEPD en un plazo de 72 horas y, si el riesgo para los afectados es alto, comunicárselo también a los propios clientes. Bajo NIS2, debe enviar una alerta temprana a INCIBE-CERT en 24 horas, una notificación detallada en 72 horas y un informe final en un mes. Los destinatarios son diferentes, los plazos son diferentes, las plantillas son diferentes, pero el proceso de detección y análisis del incidente es el mismo. Una empresa bien preparada gestionara ambas notificaciones desde un único flujo de trabajo de respuesta a incidentes; una empresa que no se haya preparado perdería horas críticas intentando entender a quién debe notificar qué cosa y en qué plazo.

Hay un matiz importante. NIS2 establece expresamente que, cuando un incidente de ciberseguridad implique también una brecha de datos personales, las autoridades de ciberseguridad deben informar a las autoridades de protección de datos —en España, a la AEPD—. Esto significa que un incidente puede generar dos procedimientos sancionadores paralelos: uno por incumplimiento de NIS2 y otro por incumplimiento del RGPD. La posibilidad de una doble sanción refuerza la importancia de una gestión integrada.

NIS2 y DORA: la ley especial para el sector financiero

El Reglamento DORA (Digital Operational Resilience Act, Reglamento (UE) 2022/2554) es la norma de resiliencia operativa digital para el sector financiero. Entró en vigor el 17 de enero de 2025 y es directamente aplicable en todos los Estados miembros sin necesidad de transposición.

DORA y NIS2 tienen un ámbito de aplicación parcialmente solapado: los bancos, las aseguradoras, las empresas de servicios de inversión, las entidades de pago y otros actores del sector financiero están cubiertos por ambas normas. Sin embargo, la relación jurídica entre ambas está clara: DORA es lex specialis respecto de NIS2. Esto significa que, en caso de conflicto, prevalece DORA.

En la práctica, una entidad financiera debe cumplir DORA en lo relativo a la gestión de riesgos TIC, la notificación de incidentes y la supervisión por reguladores financieros. NIS2 se aplica de forma supletoria en aquellos aspectos que DORA no cubra expresamente. Para los proveedores de servicios TIC que sirven al sector financiero —empresas de cloud computing, centros de datos, proveedores de software crítico—, la interacción es más compleja, ya que pueden estar sujetos a NIS2 directamente y a DORA indirectamente a través de las exigencias de sus clientes financieros.

Aspecto	NIS2	DORA
Naturaleza jurídica	Directiva (requiere transposición)	Reglamento (aplicación directa)
Ambito sectorial	18 sectores críticos (horizontal)	Sector financiero (vertical)
Relación	Ley general	Ley especial (prevalece en su ámbito)
Aplicación en España	Pendiente de transposición (2026)	En vigor desde enero 2025
Supervisor principal	Autoridades nacionales de ciberseguridad	Autoridades financieras (BdE, CNMV, DGSFP)

Otras normas del ecosistema: CER, AI Act, Cyber Resilience Act

NIS2 no existe en un vacío normativo. Forma parte de un ecosistema regulador europeo cada vez más denso:

Directiva CER (Critical Entities Resilience, Directiva (UE) 2022/2557) se centra en la resiliencia física de las entidades críticas —protección contra amenazas no cibernéticas como desastres naturales, terrorismo o sabotaje—. Mientras NIS2 protege los sistemas digitales, CER protege las infraestructuras físicas. Ambas directivas fueron adoptadas simultáneamente y están diseñadas para complementarse.

El Reglamento de Inteligencia Artificial (AI Act, Reglamento (UE) 2024/1689) establece requisitos de seguridad y gobernanza para los sistemas de IA. Las empresas que utilicen sistemas de IA clasificados como de alto riesgo —en sanidad, transporte, infraestructuras críticas— deberán cumplir tanto el AI Act como NIS2, lo que exigirá una gestión coordinada de riesgos tecnológicos.

El Cyber Resilience Act (CRA, Reglamento (UE) 2024/2847) establece requisitos de ciberseguridad para productos con elementos digitales durante todo su ciclo de vida. Mientras NIS2 se centra en las organizaciones, el CRA se centra en los productos que esas organizaciones utilizan y fabrican. La intersección es evidente: un fabricante de dispositivos IoT para el sector sanitario deberá cumplir el CRA para sus productos y NIS2 para su organización.

Para las empresas españolas, el mensaje es que la ciberseguridad y la gobernanza digital se están convirtiendo en un entramado normativo complejo pero coherente. Las empresas que adopten un enfoque integrado de cumplimiento —basado en marcos como ISO 27001, que ya cubren una parte significativa de los requisitos de todas estas normas— estarán mejor posicionadas que las que intenten cumplir cada normativa de forma aislada.

Guía práctica de cumplimiento: qué debe hacer una pyme española antes de las inspecciones

Hemos analizado el marco jurídico, las obligaciones, las sanciones y el contexto de amenazas. Ahora es el momento de aterrizar todo esto en acciones concretas. Si una pyme española opera en uno de los 18 sectores cubiertos y supera el umbral de 50 empleados o 10 millones de euros de facturación, estos son los pasos que debería dar ya —no mañana, no cuando se publique la ley en el BOE, sino ahora—.

Paso 1: Determinar si la empresa está en el ámbito de NIS2

El primer paso es el más básico y el más importante: determinar si la empresa entra en el ámbito de aplicación de la directiva. Para ello hay que responder a tres preguntas:

1. ¿Opera la empresa en alguno de los 18 sectores cubiertos? Revisar las tablas de los Anexos I y II. Atención: la clasificación es más amplia de lo que parece. Una empresa que fabrica componentes electrónicos está en el sector «Fabricación». Una empresa de logística que distribuye alimentos puede estar en el sector «Producción, transformación y distribución de alimentos». Una consultora de IT que gestiona sistemas de clientes puede ser un «proveedor de servicios gestionados» dentro de «Gestión de servicios TIC (B2B)».
2. ¿Supera los umbrales de tamaño? Más de 50 empleados O más de 10 millones de euros de facturación anual o balance general.
3. ¿Es proveedora de una entidad regulada? Aunque no cumpla los dos criterios anteriores, si la empresa es proveedora de entidades esenciales o importantes, será afectada indirectamente a través de la cadena de suministro.

Paso 2: Realizar un análisis de riesgos

El análisis de riesgos es el cimiento del cumplimiento de NIS2. Debe cubrir:

• Inventario de activos: identificar todos los sistemas de información, redes, datos, hardware, software y servicios que utiliza la empresa. Si no sabes qué tienes, no puedes protegerlo.
• Identificación de amenazas: ransomware, phishing, ataques DDoS, amenazas internas, fallos de proveedores, desastres naturales.
• Evaluación de vulnerabilidades: debilidades en la configuración de sistemas, software sin parchear, contraseñas débiles, falta de segmentación de red, ausencia de backups.
• Evaluación del impacto: qué ocurriría si cada amenaza se materializara. Cuánto tiempo podría la empresa operar sin sus sistemas críticos. Cuál sería el coste económico, legal y reputacional.
• Priorización de medidas: basándose en la probabilidad de cada amenaza y la severidad de su impacto, definir que medidas de mitigación implementar primero.

Marcos de referencia recomendados: ISO/IEC 27005 para la metodología de análisis de riesgos, MAGERIT (la metodología oficial española de análisis y gestión de riesgos de los sistemas de información, desarrollada por el Consejo Superior de Administración Electrónica), o el NIST Cybersecurity Framework 2.0.

Paso 3: Implementar las diez medidas del artículo 21

A partir del análisis de riesgos, implementar las diez medidas obligatorias. La prioridad debe basarse en el nivel de riesgo, pero una secuencia lógica sería:

1. Política de seguridad de la información: documento formal, aprobado por la dirección, que establece el marco general de ciberseguridad de la empresa.
2. MFA: implementar autenticación multifactor en todos los accesos críticos —correo electrónico corporativo, VPN, acceso remoto, paneles de administración, servicios en la nube—. Es una de las medidas más eficaces y con mejor relación coste-beneficio.
3. Backups: política de copias de seguridad siguiendo la regla 3-2-1 (tres copias, en dos soportes diferentes, una fuera del sitio). Probar regularmente la restauración.
4. Plan de respuesta a incidentes: documento que define quien hace que cuando ocurre un incidente, con procedimientos de detección, contención, erradicación, recuperación y notificación.
5. Gestión de vulnerabilidades: proceso sistemático de identificación y corrección de vulnerabilidades —actualizaciones de software, parcheo de sistemas, escaneo periódico—.
6. Control de acceso: implementar el principio de mínimo privilegio, revisar los permisos periódicamente, desactivar las cuentas inactivas.
7. Cifrado: cifrar los datos sensibles en reposo y en tránsito. Utilizar HTTPS en todas las comunicaciones externas, cifrado de disco en los portátiles corporativos, cifrado de bases de datos.
8. Formación: programa de concienciación para todos los empleados (phishing, contraseñas, ingeniería social) y formación específica para los directivos.
9. Seguridad de la cadena de suministro: evaluar la seguridad de los proveedores críticos, incluir cláusulas de ciberseguridad en los contratos, solicitar certificaciones o auditorías.
10. Evaluación de eficacia: auditorías internas o externas periódicas, pruebas de penetración, simulacros de incidentes.

Paso 4: Preparar el sistema de notificación de incidentes

Antes de que ocurra un incidente, la empresa debe tener definido:

• Quién tiene la autoridad para clasificar un incidente como «significativo» y para enviar las notificaciones.
• Los datos de contacto del CSIRT de referencia (INCIBE-CERT para sector privado, CCN-CERT para sector público).
• Plantillas predefinidas para la alerta temprana (24h) y la notificación del incidente (72h).
• Un protocolo de coordinación interno entre el equipo técnico (que detecta y contiene), el equipo legal (que evalúa las implicaciones normativas) y la dirección (que aprueba las comunicaciones).
• Un plan de comunicación de crisis que incluya la comunicación con clientes, empleados, medios de comunicación y reguladores.

Paso 5: Formalizar la gobernanza de ciberseguridad

El artículo 20 exige la implicación directa de la dirección. A nivel práctico, esto implica:

• Asignar la responsabilidad: designar una persona o equipo responsable de la ciberseguridad que reporte directamente a la dirección. En una pyme, puede ser el director de IT; en una empresa mayor, un CISO dedicado.
• Informar a la dirección regularmente: incluir la ciberseguridad en la agenda del consejo de administración o de la dirección general, con informes periódicos sobre el estado de la seguridad, los incidentes detectados, el progreso del plan de cumplimiento y las inversiones necesarias.
• Documentar las decisiones: dejar constancia escrita —en actas de consejo, memorandos internos, aprobaciones formales— de que la dirección ha aprobado las políticas de seguridad, ha sido informada de los riesgos y ha autorizado las inversiones. En caso de inspección o incidente, esa documentación será la mejor defensa contra la responsabilidad personal.
• Formar a los directivos: organizar sesiones de formación específicas para los miembros del organo de dirección, cubriendo los conceptos básicos de ciberseguridad, el marco legal de NIS2, y sus responsabilidades personales.

Paso 6: Evaluar y asegurar la cadena de suministro

La cadena de suministro es, para muchas empresas, el eslabón más débil. Las acciones concretas incluyen:

• Inventario de proveedores críticos: identificar que proveedores tienen acceso a los sistemas de la empresa, gestionan datos sensibles o proporcionan servicios esenciales para la operación. No todos los proveedores presentan el mismo nivel de riesgo: hay que priorizar.
• Evaluación de riesgo de proveedores: solicitar información sobre sus medidas de ciberseguridad mediante cuestionarios estandarizados. Verificar si disponen de certificaciones (ISO 27001, ENS) o de auditorías independientes recientes.
• Clausulas contractuales: incluir en los contratos con proveedores críticos requisitos específicos de ciberseguridad: obligación de notificar incidentes que puedan afectar a la empresa, niveles mínimos de seguridad, derecho a auditar el cumplimiento, y consecuencias contractuales del incumplimiento.
• Seguimiento continuo: la evaluación de proveedores no es un ejercicio puntual. Debe repetirse periódicamente y ante cambios significativos —como un incidente de seguridad en el proveedor, un cambio de propietario, o la subcontratación de servicios a terceros—.

Un error frecuente es confundir «proveedor crítico» con «proveedor grande». Una pequeña empresa que gestione el mantenimiento del servidor de correo electrónico o que tenga acceso remoto a los sistemas para soporte técnico puede representar un riesgo mucho mayor que un gran proveedor de suministro de oficina. El análisis debe basarse en el nivel de acceso y la criticidad del servicio, no en el tamaño del proveedor.

Paso 7: Auditar y mejorar continuamente

El cumplimiento de NIS2 no es un proyecto con fecha de finalización: es un proceso continuo. La empresa debe establecer un ciclo de mejora continua basado en:

• Auditorias periódicas —internas y, preferiblemente, también externas— para verificar el cumplimiento de las diez medidas del artículo 21.
• Pruebas de penetración al menos anuales, y más frecuentes si el análisis de riesgos lo justifica.
• Simulacros de incidentes para verificar que los procedimientos de respuesta funcionan en la práctica y que el personal sabe qué hacer.
• Revisión del análisis de riesgos ante cambios significativos: nueva infraestructura, nuevos proveedores, nuevos servicios, cambios en el entorno de amenazas.
• Actualización de políticas y procedimientos basada en los resultados de las auditorías, las pruebas y las lecciones aprendidas de incidentes reales o simulados.

La hoja de ruta resumida

Fase	Acción	Plazo recomendado
1	Determinar si la empresa está en el ámbito de NIS2	Inmediato
2	Realizar análisis de riesgos	1-2 meses
3	Implementar medidas críticas (MFA, backups, plan de incidentes)	1-3 meses
4	Desarrollar políticas y procedimientos documentados	2-4 meses
5	Formar a empleados y directivos	3-5 meses
6	Auditar la cadena de suministro	3-6 meses
7	Evaluar y asegurar proveedores críticos	3-6 meses
8	Realizar primera auditoría interna de cumplimiento	6-9 meses
9	Corregir deficiencias y establecer ciclo de mejora continua	Permanente

ISO 27001 como camino hacia el cumplimiento

El mapa de ENISA: como se relacionan NIS2 e ISO 27001

ENISA ha publicado una guía técnica de implementación de NIS2 que incluye un mapeo detallado de los requisitos de la directiva con los controles de ISO/IEC 27001:2022, ISO/IEC 27002:2022 y el NIST Cybersecurity Framework 2.0. La conclusión principal es que una empresa certificada en ISO 27001 ya cubre una parte significativa de los requisitos de NIS2, pero no todos.

Según los análisis de ENISA y de consultoras especializadas, ISO 27001 cubre aproximadamente 12 de los 15 pasos necesarios para el cumplimiento de NIS2. Las áreas donde ISO 27001 es insuficiente o incompleta incluyen: los requisitos específicos de notificación de incidentes (la cascada de 24-72-30 días), las obligaciones de gobernanza del artículo 20 (responsabilidad personal de los directivos), y algunos aspectos específicos de la seguridad de la cadena de suministro.

Para las pymes que buscan un punto de partida solido, ISO 27001 es probablemente la mejor inversión: proporciona un marco sistemático, reconocido internacionalmente, que cubre la mayor parte de las obligaciones de NIS2 y que además facilita el cumplimiento de otras normativas como el RGPD y DORA. La certificación en ISO 27001 no garantiza automáticamente el cumplimiento de NIS2, pero reduce significativamente el esfuerzo necesario y demuestra ante las autoridades de supervisión un compromiso serio con la ciberseguridad.

El Esquema Nacional de Seguridad (ENS) en el contexto de NIS2

Para las entidades del sector público español y para los proveedores que trabajan con la administración pública, el Esquema Nacional de Seguridad (ENS, regulado por el Real Decreto 311/2022) es el marco de referencia obligatorio. El ENS ya establece medidas de seguridad detalladas, clasificación de sistemas por niveles (bajo, medio, alto) y requisitos de auditoría que se alinean en gran medida con las exigencias de NIS2.

La transposición española de NIS2 deberá articular la relación entre la nueva ley y el ENS, evitando duplicidades pero garantizando que las entidades públicas y sus proveedores cumplan con ambos marcos. Para las empresas que ya cumplen con el ENS, la transición a NIS2 será menos traumatica, ya que muchos de los controles ya están implementados.

Errores frecuentes: lo que las empresas no deben hacer

La experiencia de la implementación del RGPD en 2018 ofrece lecciones valiosas sobre los errores que las empresas cometen cuando se enfrentan a una nueva regulación de gran alcance. Estos son los errores que ya se están observando en relación con NIS2 —y que conviene evitar—.

Error 1: Esperar a que se publique la ley nacional

El razonamiento es comprensible pero equivocado: «Si la ley española aún no está en vigor, no tengo obligación de cumplir». Hay tres razones por las que esperar es un error. Primera, las medidas de ciberseguridad no se implementan de la noche a la mañana: un programa serio de cumplimiento requiere entre 6 y 12 meses. Segunda, el efecto directo de las directivas no transpuestas permite invocar sus disposiciones ante tribunales nacionales. Tercera, el efecto cascada ya está operando: las grandes empresas ya están exigiendo cumplimiento a sus proveedores, independientemente del estado de la transposición.

Error 2: Tratar el cumplimiento como un proyecto de IT

NIS2 no es un problema técnico que pueda resolverse comprando un firewall nuevo o contratando a un proveedor de ciberseguridad. Es un problema de gobernanza corporativa que requiere la implicación de la dirección, del departamento legal, de recursos humanos (formación), de compras (cadena de suministro), y, por supuesto, de IT. Delegar NIS2 exclusivamente en el departamento de IT es ignorar el artículo 20 —la responsabilidad personal de los directivos— y garantizar un cumplimiento superficial e incompleto.

Error 3: Confundir documentación con seguridad

Escribir políticas de seguridad impecables que nadie lee ni aplica es un clásico de la gestión normativa. NIS2 exige medidas «técnicas, operativas y organizativas». Las políticas documentadas son el componente organizativo, pero deben ir acompañadas de controles técnicos reales (MFA implementado, no solo previsto en un documento) y de prácticas operativas verificables (backups que realmente se realizan, se prueban y se pueden restaurar). Las autoridades de supervisión no se limitarán a revisar la documentación: verificarán que las medidas están realmente implementadas y funcionan.

Error 4: Ignorar la cadena de suministro

Muchas empresas se centran exclusivamente en proteger su propio perímetro y olvidan que NIS2 les obliga a evaluar y gestionar los riesgos de sus proveedores. El caso de Iberdrola lo demostró: la brecha se originó en un proveedor externo. La cadena de suministro es, estadisticamente, uno de los vectores de ataque más frecuentes y más eficaces, precisamente porque suele ser el punto menos controlado.

Error 5: Subestimar el plazo de 24 horas

Las empresas que no han ensayado su procedimiento de notificación de incidentes descubren, cuando sufren un ataque real, que 24 horas es un plazo extremadamente corto. Identificar al responsable de la notificación, clasificar el incidente como «significativo», recopilar la información mínima requerida, contactar con el CSIRT de referencia —todo esto lleva tiempo, y bajo la presión de un incidente activo, el tiempo se comprime dramáticamente—. La única forma de estar preparado es haber definido y ensayado el procedimiento antes de necesitarlo.

El cambio de paradigma: de la seguridad reactiva a la seguridad por diseño

El fin de la ciberseguridad como gasto prescindible

NIS2 representa un cambio de paradigma en la forma en que Europa —y España en particular— concibe la ciberseguridad empresarial. Durante decadas, la ciberseguridad fue tratada como un gasto operativo, una partida del presupuesto de IT que podía recortarse cuando los tiempos eran difíciles. NIS2 la eleva a obligación legal, a requisito de gobierno corporativo, a responsabilidad personal de los máximos directivos.

Este cambio tiene raices profundas. La creciente dependencia digital de la economía, la profesionalización del cibercrimen, la utilización de ataques ciberneticos como arma geopolítica, y la interconexión de las cadenas de suministro globales han convertido la ciberseguridad en una cuestión de interés público que no puede dejarse exclusivamente en manos de la iniciativa privada. Del mismo modo que la regulación medioambiental obligó a las empresas a internalizar los costes de la contaminación, NIS2 obliga a las empresas a internalizar los costes de la inseguridad digital.

La ciberseguridad como ventaja competitiva

Para las empresas que adopten una perspectiva estratégica, NIS2 no es solo un coste de cumplimiento: es una oportunidad competitiva. En un mercado donde los ciberataques son cada vez más frecuentes y los clientes son cada vez más conscientes de los riesgos, poder demostrar un nivel elevado de ciberseguridad —certificaciones, auditorías, políticas documentadas, formación continua— se convierte en un diferenciador comercial.

Esto es especialmente relevante para las pymes que forman parte de cadenas de suministro de grandes empresas. A medida que las entidades reguladas por NIS2 endurezan sus requisitos de seguridad para proveedores, las pymes que ya cumplan estarán en una posición privilegiada para mantener y ampliar sus relaciones comerciales. Las que no cumplan, perderán contratos.

El horizonte de 2026: un año decisivo

2026 es el año en que NIS2 deja de ser una promesa y se convierte en una realidad operativa en España. La aprobación definitiva de la Ley de Coordinación y Gobernanza de la Ciberseguridad es cuestión de meses. Las autoridades de supervisión están preparando sus equipos y sus procedimientos de inspección. Las entidades esenciales pueden esperar las primeras inspecciones programadas a lo largo del año. Las entidades importantes, aunque sujetas a supervisión reactiva, no deben confiarse: un solo incidente significativo puede desencadenar una inspección que revele deficiencias de cumplimiento generalizadas.

El mensaje para las empresas españolas es inequivoco: el momento de actuar es ahora. No después de que se publique la ley en el BOE. No después de la primera inspección. No después del primer incidente. Ahora. Porque la ciberseguridad no es un proyecto que se implementa de la noche a la mañana: es un proceso continuo que requiere tiempo, recursos y, sobre todo, un cambio de mentalidad en la dirección de la empresa.

La Directiva NIS2 no pretende convertir a cada empresa en una fortaleza inexpugnable. Pretende elevar el nivel mínimo de seguridad de la economía europea a un estándar que reduzca significativamente la superficie de ataque disponible para los ciberdelincuentes. Pretende que un hospital no tenga que atender urgencias con lápiz y papel. Que una aerolinea no tenga que pedir a sus clientes que cancelen sus tarjetas de crédito. Que los datos de 850.000 personas no aparezcan a la venta en un foro de la dark web porque un proveedor externo tenía una vulnerabilidad sin parchear.

Es, en definitiva, un reconocimiento de que en la economía digital del siglo XXI, la ciberseguridad no es un lujo ni un gasto discrecional. Es una infraestructura básica, tan esencial como la electricidad, el agua corriente o las cerraduras de las puertas. Y las empresas que no lo entiendan a tiempo pagarán un precio muy alto —no solo en multas, sino en la propia supervivencia de su negocio—.

Tres preguntas que todo directivo debería hacerse hoy

Para cerrar este análisis con un ejercicio práctico, cualquier directivo de una empresa española que opere en uno de los 18 sectores cubiertos —o que sea proveedora de una entidad que lo haga— debería poder responder hoy a estas tres preguntas:

Primera: «¿Sé qué pasa con mi empresa si nuestros sistemas dejan de funcionar mañana?» Si la respuesta es «no lo se» o «depende», falta un análisis de impacto en el negocio y un plan de continuidad. Son las medidas (a) y (c) del artículo 21.

Segunda: «¿Puedo demostrar documentalmente que he aprobado y supervisado las medidas de ciberseguridad de mi empresa?» Si la respuesta es no, el directivo está expuesto a responsabilidad personal bajo el artículo 20. Las actas de consejo, los memorandos de aprobación de políticas y los registros de formación no son burocracia: son la defensa legal del directivo.

Tercera: «¿Si sufrimos un ciberataque a las 3 de la madrugada de un sábado, sabemos a quién llamar y qué hacer en las primeras 24 horas?» Si la respuesta es no, falta un plan de respuesta a incidentes operativo y ensayado. Es la medida (b) del artículo 21 y el requisito previo para cumplir con el artículo 23.

Si un directivo no puede responder afirmativamente a las tres preguntas, el trabajo debe empezar hoy. No mañana, no después de vacaciones, no cuando se publique la ley en el BOE. Hoy. Porque los ciberdelincuentes no esperan a que las empresas estén preparadas. Y a partir de 2026, tampoco lo harán los inspectores.