ISO 27001 y NIS2: qué cambia en España

«Estamos certificados en la ISO 27001, así que NIS2 lo tenemos resuelto.» La frase aparece en casi todas las primeras conversaciones con un responsable de seguridad de una empresa certificada. Está medio acertada. La otra mitad cuesta dinero.

Y en España hay un matiz que casi ninguna página recoge: la pregunta ni siquiera se plantea en los términos en que la plantea el mercado, porque la directiva todavía no es derecho español. Eso no significa que no cambie nada. Significa que lo que cambia llega por otro sitio.

La respuesta corta cabe en cinco palabras, y las dos mitades pesan igual: contractualmente, mucho; estatutariamente, nada todavía.

Escribimos esto sabiendo cuál es nuestro interés. Vendemos pentesting y auditoría, y el miedo regulatorio se vende solo. Por eso hemos preferido citar los textos antes que resumirlos, y decir también dónde el texto no exige lo que nos convendría que exigiera.

La respuesta corta: contractualmente mucho, estatutariamente nada todavía

Una directiva europea no se aplica directamente a las empresas: obliga a los Estados miembros a transponerla. Mientras no haya ley española, los umbrales, los sectores, el registro y el régimen sancionador no están fijados en derecho interno, y ninguna autoridad española puede inspeccionarte ni multarte por NIS2. Eso es todo lo que hace falta decir aquí; el argumento completo, con el registro de EUR-Lex y el expediente de infracción, está desarrollado en NIS2 en España: qué obliga hoy y qué no.

Lo que sí cambia, y cambia ya, es lo que te piden por escrito quienes tienen un motivo para pedirlo:

• el cliente regulado en un Estado que sí ha transpuesto la directiva, que traslada la obligación a su cadena de suministro por contrato;
• el pliego del sector público, que arrastra el Esquema Nacional de Seguridad;
• el cuestionario de proveedor de una aseguradora, de un grupo cotizado o de un integrador;
• y un reglamento europeo de ejecución que, por ser reglamento, no espera a nadie.

Ese es el terreno real. La parte técnica que te van a pedir en todos esos casos es la misma, y es exactamente la que un SGSI ya produce.

Qué te da realmente un SGSI

ISO/IEC 27001 es una norma internacional que describe un sistema de gestión de la seguridad de la información: un SGSI. Sus capítulos 4 a 10 son la parte obligatoria —contexto, liderazgo, planificación, apoyo, operación, evaluación del desempeño y mejora— y son los que se auditan. El Anexo A aporta 93 controles agrupados en cuatro temas: organizativos (5.1 a 5.37), de personas (6.1 a 6.8), físicos (7.1 a 7.14) y tecnológicos (8.1 a 8.34). La ISO/IEC 27002:2022 explica cómo implantar cada uno.

La lógica es sencilla y conviene tenerla clara antes de comparar nada con una directiva: defines qué proteges, aprecias los riesgos, eliges controles, justificas las exclusiones en la declaración de aplicabilidad (capítulo 6.1.3) y demuestras que el conjunto funciona y mejora. Lo que se certifica no es que seas seguro. Lo que se certifica es que tienes un sistema de gestión que funciona sobre el alcance que tú mismo has declarado.

Quién expide el certificado

El certificado lo emite un organismo de certificación acreditado conforme a la norma UNE-EN ISO/IEC 17021-1. En España el organismo nacional de acreditación es ENAC, designado por el Real Decreto 1715/2010 en aplicación del Reglamento (CE) 765/2008, y la lista de organismos acreditados es pública. Las reglas de imparcialidad de la 17021-1 impiden que un organismo certifique un sistema de gestión sobre el que ha prestado consultoría.

Dos consecuencias prácticas que se olvidan a menudo:

Un certificado de otro país de la UE vale aquí. El artículo 11, apartado 2, del Reglamento (CE) 765/2008 obliga a las autoridades nacionales a reconocer la equivalencia de los servicios prestados por los organismos de acreditación que han superado la evaluación por pares, y a aceptar los certificados de los organismos que estos acreditan. Si tu certificado lo emitió un organismo acreditado en Alemania o en Países Bajos, es tan válido en un pliego español como uno acreditado por ENAC. Esto no ocurre con el ENS, que es un esquema específicamente español, y la diferencia está explicada en quién puede auditar el ENS.

El ciclo es de tres años. Auditoría inicial en dos fases, auditorías de seguimiento anuales y renovación al tercer año. Ese calendario importa para lo que viene después: la evidencia técnica que presentas tiene que estar viva en cada visita, no solo en la inicial.

Lo que un certificado no dice

Un certificado no dice que tus sistemas resistan un ataque. Dice que hay un sistema de gestión que identifica riesgos, elige controles y los revisa. Es mucho, y es otra cosa. Esta distinción es la que explica la mayor parte de los desencuentros entre una entidad auditora y un equipo técnico, y la desarrollamos en cómo prepararse para una auditoría de ciberseguridad.

Qué pide el artículo 21 de la directiva

El artículo 21, apartado 2, de la Directiva (UE) 2022/2555 enumera diez familias de medidas. Las entidades esenciales e importantes deben adoptar medidas técnicas, operativas y de organización adecuadas y proporcionadas, con un enfoque de todos los riesgos, y esas medidas deben incluir, como mínimo:

Nada de esta lista exige una tecnología que no conozcas. Lo que exige es que cada familia esté cubierta, documentada y demostrable. La letra g) habla de «formación en ciberseguridad» porque así lo dice el texto oficial; en nuestro vocabulario y en el del mercado español eso es concienciación, y la diferencia no es cosmética: una cosa es un curso y otra una campaña medida con resultados.

Dos avisos sobre el resto del artículo, que casi nunca se citan:

• El apartado 1 exige que las medidas garanticen un nivel de seguridad adecuado a los riesgos existentes, y el apartado 5 habilita a la Comisión a adoptar actos de ejecución que concreten los requisitos técnicos para ciertos tipos de entidad. Ese poder ya se ha ejercido, y es de donde sale el reglamento del que hablamos más abajo.
• El apartado 3 pide a las entidades tener en cuenta las vulnerabilidades específicas de cada proveedor directo y la calidad general de sus productos y prácticas de ciberseguridad, incluidos sus procedimientos de desarrollo seguro. Es la frase que acaba convertida en el cuestionario que recibes.

Dónde responde ya el Anexo A

El solape con la ISO/IEC 27001:2022 es directo en casi todas las familias. Esta es la tabla que conviene rellenar una vez y reutilizar siempre:

Si tu SGSI vive de verdad —y no solo la semana de la auditoría—, la mayor parte del trabajo ya está hecho. Lo que falta no es una estructura nueva: es una tabla de correspondencia, las mismas evidencias reetiquetadas con las referencias de la directiva. Es media jornada de trabajo documental y ahorra semanas de discusión.

Por qué aquí no vas a leer un porcentaje

Se lee mucho que la ISO 27001 cubriría «en torno a un 70 %» de NIS2. Esa cifra circula de un sitio a otro sin fuente verificable y no significa nada: la cobertura real depende del alcance de tu certificación y de la madurez efectiva de tus controles, no de una media de mercado. Un certificado estrecho sobre un servicio ancho puede cubrir muy poco, y uno amplio con controles vivos puede cubrirlo casi todo. Haz la correspondencia línea a línea. Sustituye con ventaja a un número prestado.

Dónde se acaba el SGSI

Tres obligaciones de la directiva no tienen equivalente posible en una norma técnica. Ninguna cantidad de certificación las cumple.

1. El registro ante la autoridad

La directiva prevé que los Estados miembros establezcan la lista de entidades esenciales e importantes (artículo 3, apartado 4) y que determinadas entidades digitales comuniquen a la autoridad competente la información que las identifica (artículo 27). Una norma no conoce ese trámite y no puede conocerlo: es un registro administrativo, no un control de seguridad.

En España, hoy, no hay dónde registrarse. No existe la lista, no existe la autoridad designada bajo NIS2 y no existe el procedimiento. Lo que existe es el régimen anterior —Real Decreto-ley 12/2018 y Real Decreto 43/2021—, que alcanza a quien ya estuviera designado dentro de su ámbito. Cuando llegue la ley, este trámite será administrativo y rápido; lo que no será rápido es el resto.

2. Los plazos de notificación del artículo 23

Los controles 5.24 a 5.28 del Anexo A piden un proceso de gestión de incidentes: quién califica, quién decide, cómo se documenta. Lo que una norma no conoce es un plazo oponible a una autoridad.

El artículo 23 de la directiva articula tres tiempos: alerta temprana en 24 horas, notificación del incidente en 72 horas e informe final en un mes. Tu procedimiento actual es una buena base, pero le falta una rama: quién decide, en cuestión de horas y fuera del horario de oficina, que un incidente es significativo, y quién notifica. No es un problema de procedimiento. Es un problema de reloj y de guardia.

Conviene añadir un matiz honesto, porque es el que hace creíble todo lo demás: esos plazos no son exigibles hoy en España por NIS2. No hay autoridad a la que notificar bajo ese régimen. Pero sí aparecen ya, palabra por palabra, en contratos y en acuerdos de nivel de servicio que firman clientes regulados fuera de España. Ahí no te los exige el Estado: te los exige tu cliente, y el incumplimiento es contractual.

3. La responsabilidad del órgano de dirección

El artículo 20 de la directiva pide a los órganos de dirección que aprueben las medidas de gestión de riesgos de ciberseguridad, que supervisen su aplicación, y prevé que puedan ser considerados responsables del incumplimiento. Su apartado 2 exige que sus miembros «sigan una formación» para adquirir conocimientos y capacidades suficientes que les permitan detectar riesgos y evaluar las prácticas de gestión de riesgos.

El capítulo 5.1 de la ISO/IEC 27001 pide liderazgo y compromiso, pero se dirige a la organización, no a la persona que se sienta en el consejo. La diferencia es de destinatario, y es la que no se cierra con un certificado.

En la práctica: la aprobación tiene que quedar trazada y apoyarse en algo verificable. Un informe de auditoría del SGSI no siempre basta, porque describe el estado del sistema de gestión y no la resistencia real de los sistemas. Es también la razón por la que una sesión de concienciación dirigida al comité de dirección tiene un valor propio, distinto del de la concienciación del resto de la plantilla.

Y el hueco que nadie mira: el alcance

Es el más caro y el más discreto, y no aparece en ninguna lista de diferencias.

En la ISO 27001 eres tú quien delimita el alcance, y muchos certificados cubren un recorte cuidadosamente elegido. En la lógica de la directiva, el perímetro lo determina el servicio prestado, el sector y el tamaño. Si tu declaración de aplicabilidad cubre «la explotación del centro de datos de Madrid» y el servicio que interesa a tu cliente es la plataforma completa, tienes un certificado que no cubre la parte que te preguntan.

Los casos frecuentes son siempre los mismos tres: un certificado que cubre la matriz y no las filiales; uno que cubre la infraestructura y no la aplicación expuesta; y uno heredado de un fabricante, que cubre su producto y no tu explotación.

Comparar las dos columnas —alcance declarado frente a servicio realmente prestado— no cuesta nada y se hace antes de gastar un euro.

Por dónde te llega hoy la obligación en España

Aquí está el cambio real, y no tiene nada que ver con el BOE.

1. Tu cliente, que sí está regulado

Es la vía más frecuente y la peor entendida. Una entidad esencial o importante en un Estado que ya transpuso la directiva tiene que gestionar la seguridad de su cadena de suministro —artículo 21.2.d)— y tener en cuenta las vulnerabilidades específicas de cada proveedor directo —artículo 21.3—. La única herramienta que tiene para hacerlo es la que te llega a ti: una cláusula, un cuestionario y, cada vez más, la petición de un informe de pruebas técnicas con fecha.

La consecuencia es contraintuitiva y conviene decirla sin adornos: tu empresa puede estar sujeta a requisitos derivados de NIS2 antes de que exista una ley española de NIS2, porque la obligación viaja por el contrato y el contrato no espera a la transposición. Quien te lo exige no es una autoridad, y por eso no hay sanción administrativa; lo que hay es resolución del contrato, penalizaciones o, simplemente, no ganar el concurso.

2. El sector público, vía ENS

El Esquema Nacional de Seguridad alcanza a una empresa privada por el artículo 2.3 del RD 311/2022, cuando «en virtud de una relación contractual» presta servicios o provee soluciones a entidades del sector público «para el ejercicio por estas de sus competencias y potestades administrativas». Las condiciones son acumulativas y el mecanismo son los pliegos.

Esto es un régimen distinto de NIS2 y con exigencias propias, incluida la medida del Anexo II que el decreto titula «Pruebas de penetración» en el refuerzo R6 de op.mon.3, aplicable en categoría ALTA. Qué obliga exactamente y a quién está desarrollado en qué exige realmente el ENS sobre pentesting. Merece la pena saber que el anteproyecto español, si llega a ley en su forma actual, apoyaría su parte técnica en los perfiles de cumplimiento específicos del propio ENS, de modo que el trabajo que hagas ahí no se pierde.

3. El reglamento europeo que no espera a nadie

El Reglamento de Ejecución (UE) 2024/2690 de la Comisión, de 17 de octubre de 2024, se adoptó al amparo del artículo 21, apartado 5, de la directiva. Es un reglamento, no una directiva: se aplica directamente y el retraso español no le afecta.

Su ámbito es concreto —proveedores de servicios DNS, registros de nombres de dominio de primer nivel, proveedores de computación en nube y de centros de datos, redes de distribución de contenidos, proveedores de servicios gestionados y de servicios de seguridad gestionados, mercados en línea, motores de búsqueda, plataformas de redes sociales y prestadores de servicios de confianza— y su anexo contiene, en el punto 6.5, «Pruebas de seguridad», lo que muchos SGSI tienen a medias:

• 6.5.1 establecer políticas y procedimientos de pruebas de seguridad;
• 6.5.2 determinar la necesidad, el alcance, la frecuencia y el tipo de prueba a partir del análisis de riesgos, realizarlas «de acuerdo con una metodología de prueba documentada» y documentar tipo, alcance, fecha y resultados, incluidos los hallazgos críticos, y corregirlos;
• 6.5.3 revisar esas políticas y procedimientos a intervalos planificados.

Y ahora la parte que no nos conviene: el punto 6.5 no exige que quien realiza las pruebas sea externo ni independiente. Un equipo interno que cumpla la letra del texto la cumple. Lo decimos aunque vendamos pruebas externas, porque cualquier otra cosa sería vender una obligación inventada.

El control 8.29 del Anexo A y el punto 6.5 son el mismo trabajo con dos etiquetas. Si estás en el ámbito del reglamento, el argumento para cerrar el presupuesto no es NIS2: es este punto, que ya te obliga.

4. El que ya estaba: el artículo 32 del RGPD

Mientras todo lo anterior se resuelve, el artículo 32.1.d) del RGPD lleva aplicándose desde 2018 a cualquier tratamiento de datos personales, y exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento».

Conviene ser exacto, porque el mercado exagera aquí con frecuencia: el RGPD no nombra el pentesting. Exige un proceso regular de verificación y evaluación, y deja la forma en tus manos. Un pentest con informe y verificación de correcciones es una manera muy sólida de acreditarlo, y no es la única.

El denominador común: demostrar que las medidas aguantan

Hay un punto donde los cuatro marcos piden literalmente lo mismo, y donde los cuatro tropiezan igual.

El control 8.8 del Anexo A pide gestión de las vulnerabilidades técnicas: conocer las vulnerabilidades de los sistemas en uso, evaluar la exposición y actuar. El control 8.29 pide pruebas de seguridad durante el desarrollo y en la aceptación. El artículo 21.2, letras e) y f) de la directiva pide la gestión y divulgación de las vulnerabilidades y procedimientos para evaluar la eficacia de las medidas. El punto 6.5 del reglamento de ejecución pide pruebas documentadas con metodología. Y el artículo 32.1.d) del RGPD pide verificación regular.

Es un único trabajo con cuatro etiquetas:

1. identificar y priorizar de forma continua mediante un análisis de vulnerabilidades;
2. comprobar periódicamente, con un test de intrusión, que los controles detienen de verdad a quien ataca;
3. cerrar el ciclo con un retest que acredite por escrito que lo encontrado está corregido.

La diferencia entre lo que encuentra una herramienta y lo que encuentra una persona está desarrollada en análisis de vulnerabilidades o pentest, y las metodologías que seguimos están publicadas página a página en metodologías de testing precisamente para que se puedan comparar con las de cualquier otro.

La condición para que un solo proyecto sirva a los cuatro marcos es una sola: que el informe enlace cada hallazgo con el requisito que le corresponde. Un hallazgo etiquetado con «A.8.8» y con «art. 21.2.e)» se lee igual de bien en una auditoría de certificación que en un cuestionario de cliente. Sin ese etiquetado, tienes un buen informe técnico que alguien tendrá que traducir dos veces. Es lo que entregamos en pentesting para ISO 27001 y en pentesting para NIS2.

Si lo que necesitas es una mirada de conjunto sobre controles, procesos y evidencias, y no un test de intrusión, entonces lo que buscas es una auditoría de ciberseguridad. No es lo mismo y no se sustituyen.

Si ya tienes el certificado: cuatro movimientos

1. Compara los alcances. ¿Cubre tu declaración de aplicabilidad el servicio por el que te preguntan? Es la diferencia más frecuente y la más cara. Media hora de trabajo.
2. Construye la tabla de correspondencia. Artículo 21.2 a la izquierda, controles del Anexo A a la derecha. En la mayoría de las filas solo tendrás que copiar la referencia de una evidencia que ya existe.
3. Cierra los tres huecos. Cadena de notificación con los tiempos del artículo 23, preparación del registro para cuando exista, y aprobación trazada por el órgano de dirección con fecha y acta.
4. Demuestra la eficacia. El pentest que ya haces para el 8.29 cubre también la letra f) del artículo 21.2 y el punto 6.5 del reglamento de ejecución, siempre que el informe lo diga.

Para una organización con el SGSI en marcha, el esfuerzo realista se cuenta en semanas y es mayoritariamente documental. Quien te diga que hay que empezar de cero no ha mirado tu declaración de aplicabilidad.

Si no lo tienes

No existe ninguna obligación de certificarse: la directiva exige medidas, no una norma. Pero el Anexo A sigue siendo el plano de obra más practicable que hay, porque convierte objetivos en 93 controles que alguien ya redactó y probó.

Dos caminos, los dos defendibles:

• Con certificación, si de todas formas necesitas la prueba para cuestionarios de proveedor y licitaciones. El ciclo son tres años con auditorías de seguimiento anuales, y el certificado es hoy, en España, el argumento que más puertas abre precisamente porque la ley no ha llegado.
• Sin certificación, usando el Anexo A como estructura. Te ahorras el coste del organismo y pierdes el argumento comercial.

En los dos casos la parte técnica es idéntica, y es la que no se traspasa: hay que poder demostrar que los controles aguantan.

El caso de las entidades financieras

Una precisión que el mercado confunde a menudo, y que decide qué régimen citas en una propuesta. El Reglamento (UE) 2022/2554 (DORA) es un régimen propio para las entidades financieras, con sus propios requisitos de prueba y de gestión del riesgo de terceros —su artículo 30 fija los contenidos contractuales mínimos de los contratos de servicios TIC—. Y la propia Directiva (UE) 2022/2555, en su artículo 4, prevé que un acto jurídico sectorial de la Unión con requisitos al menos equivalentes en sus efectos prevalezca sobre ella.

Y una exclusión nuestra, dicha antes de que la pregunte nadie: los ejercicios TLPT de los artículos 26 y 27 de DORA son un régimen aparte, con criterios propios sobre quién puede ejecutarlos. Un ejercicio de Red Team de Haxoris puede ser preparación previa, pero no lo sustituye y no lo realizamos. Vender «cumplimiento NIS2» a un banco o a una aseguradora es señalar el régimen equivocado.

Lo que hacemos y lo que no

Lo decimos sin rodeos, porque lo único que costaría más caro que no tener una acreditación sería dejar la duda en el aire.

• No somos organismo de certificación. Un certificado ISO/IEC 27001 lo expide un organismo acreditado conforme a la UNE-EN ISO/IEC 17021-1; en España la acreditación corresponde a ENAC, designada por el Real Decreto 1715/2010. Haxoris no está acreditada por ENAC, no expide certificados ISO/IEC 27001 y no realiza auditorías de certificación.
• Tampoco certificamos el ENS. No expedimos certificaciones ni declaraciones de conformidad con el Esquema Nacional de Seguridad. Quién puede firmar qué está desglosado en quién puede auditar el ENS.
• Lo que aportamos es la materia técnica: un test de intrusión orientado a los controles del Anexo A —8.8 y 8.29 en particular— con un informe que tu entidad auditora pueda leer, una auditoría interna o una preauditoría antes del paso del organismo certificador, y un retest incluido, sin coste adicional, que acredita que los hallazgos están corregidos.
• Somos un proveedor europeo, una empresa establecida en la Unión Europea: tus informes y las evidencias del proyecto permanecen en la UE, el RGPD se aplica directamente, no hay transferencia internacional del capítulo V y sabes por su nombre quién ejecuta la prueba. Si esa es tu duda de compra, está tratada en contratar una empresa de pentesting no española.

ISO 27001 y NIS2 en España: preguntas frecuentes

¿No tienes claro si tu certificado cubre el servicio por el que te preguntan? Cuéntanos el alcance declarado y la cláusula que has recibido: te respondemos por escrito en 24 horas, también cuando la respuesta sea que con lo que ya tienes es suficiente. Solicita tu presupuesto o empieza por pentesting para ISO 27001.

Nuestros servicios relacionados: pentesting para preparar tu certificación ISO 27001 · pentesting para prepararte ante la Directiva (UE) 2022/2555 (NIS2) · pentesting y tests de intrusión de tus aplicaciones e infraestructuras · análisis de vulnerabilidades de tus sistemas y aplicaciones · auditoría de ciberseguridad de tu entorno tecnológico