Pentesting industrial: OT, ICS e IoT

Qué obliga realmente en España

El mercado español vende ciberseguridad industrial a golpe de NIS2. Conviene ser exactos, porque a 12 de septiembre de 2026 la situación no es la que describen la mayoría de las páginas de proveedores.

NIS2 no está transpuesta

La Directiva (UE) 2022/2555 todavía no es derecho español. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad recibió una primera lectura en el Consejo de Ministros el 14 de enero de 2025 y no ha llegado a las Cortes Generales. El 9 de julio de 2026 la Comisión Europea decidió llevar a España ante el Tribunal de Justicia de la Unión Europea por esa falta de transposición, en el procedimiento de infracción INFR(2024)0270. Lo que sigue vigente, y lo que un operador industrial cumple hoy, es el Real Decreto-ley 12/2018 —art. 16, medidas técnicas y organizativas adecuadas y proporcionadas— junto con su reglamento de desarrollo, el Real Decreto 43/2021: política de seguridad de las redes y sistemas de información, responsable de seguridad de la información, análisis de riesgos y notificación de incidentes al CSIRT de referencia, que para el sector privado es INCIBE-CERT. Lo desarrollamos en NIS2 en España: qué obliga hoy y qué no.

Lo que sí es directamente aplicable: el Reglamento (UE) 2024/2690

Un reglamento de ejecución no necesita transposición. El Reglamento de Ejecución (UE) 2024/2690 concreta los requisitos técnicos y metodológicos de las medidas del art. 21.2 de NIS2 para determinadas entidades del sector digital: proveedores de servicios en la nube, centros de datos, redes de distribución de contenidos, proveedores de servicios gestionados y de servicios gestionados de seguridad, entre otros. Si tu plataforma IoT presta alguno de esos servicios, ya te alcanza. Su Anexo, punto 6.5, «Pruebas de seguridad», exige una política de pruebas documentada, un alcance y una frecuencia basados en el riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. Ahí encaja un pentest con precisión: no porque lo diga un folleto comercial, sino porque el texto pide evidencia documentada de haberlo hecho.

ENS: cuando la planta es pública o presta un servicio público

Aguas municipales, transporte metropolitano, alumbrado, climatización y control de edificios de la Administración: buena parte del OT español está dentro del Esquema Nacional de Seguridad. El Real Decreto 311/2022 fija en su art. 31 una auditoría regular ordinaria al menos cada dos años, y en el art. 38 separa la autoevaluación, propia de la categoría BÁSICA, de la certificación exigida en MEDIA y ALTA. En el Anexo II, la medida [op.mon.3] R6 incorpora el subrequisito [op.mon.3.r6.3], «Pruebas de penetración», exigible en categoría ALTA. Y desde BÁSICA, el op.nub.1.2 a) reclama «Auditoría de pruebas de penetración (pentesting)» sobre los servicios en la nube de terceros que no sean conformes con el ENS, lo que afecta de lleno a las plataformas IoT alojadas fuera de ese marco. Más detalle en qué exige realmente el ENS sobre pentesting.

Conviene decir dónde termina nuestro papel: realizamos las pruebas técnicas que sirven de insumo a esa auditoría y documentamos alcance, método, hallazgos y corrección. Haxoris no está acreditada por ENAC, no es entidad de certificación y no expide certificaciones de conformidad con el ENS. Quien audita y quien certifica es un tercero.

RGPD, DORA y el Cyber Resilience Act

El art. 32.1.d) del RGPD exige un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas: un contador inteligente, una cámara conectada o un dispositivo de salud tratan datos personales y entran de lleno. DORA, el Reglamento (UE) 2022/2554, se aplica desde el 17 de enero de 2025 y su art. 26 impone pruebas guiadas por amenazas al menos cada tres años a las entidades financieras designadas; ese ejercicio no es nuestro terreno y lo explicamos más abajo. Y el Reglamento (UE) 2024/2847, el Cyber Resilience Act, es la fecha que quien fabrica debería tener en la pared: sus obligaciones de notificación de vulnerabilidades explotadas activamente se aplican desde el 11 de septiembre de 2026 y el grueso del reglamento desde el 11 de diciembre de 2027. No prescribe un test de intrusión con ese nombre, pero exige demostrar que el producto cumple unos requisitos esenciales de ciberseguridad y que sus vulnerabilidades se gestionan durante el periodo de soporte. Un pentest es la vía habitual de demostrarlo.

Última verificación de este apartado: 12 de septiembre de 2026.

Alcance y planificación: qué se acuerda antes de tocar nada

En un entorno industrial, el acuerdo de alcance pesa más que el número de días vendidos, porque define sobre todo qué no se toca. Se cierra en una o dos sesiones y fija:

• los objetivos: rangos de direcciones IP, segmentos de la red de planta, referencias y versiones de firmware, frecuencias de radio implicadas, cuentas por perfil y suscripciones de nube;
• las exclusiones: sistemas instrumentados de seguridad, equipos bajo garantía del fabricante, denegación de servicio, escritura sobre autómatas en producción y cualquier acción destructiva;
• la ventana de intervención —una parada programada o de mantenimiento para lo que sea intrusivo— y un contacto tuyo localizable durante todo el proyecto;
• las reglas de actuación (rules of engagement): profundidad de explotación autorizada, tratamiento de datos reales y qué se hace ante un hallazgo crítico, que te comunicamos en el momento sin esperar al informe;
• el entorno: banco de pruebas o celda espejo cuando existe; producción con precauciones reforzadas cuando no, y siempre con un criterio de parada acordado por escrito.

La distinción que más disgustos ahorra es la del método. Sobre una red OT empezamos siempre en modo pasivo: captura y análisis de tráfico en un puerto espejo, inventario a partir de lo que se ve pasar, revisión en frío de configuraciones y de reglas de firewall. Nada de eso interactúa con un autómata. El sondeo activo, la interacción con un PLC o la manipulación de una trama se planifican, se anuncian y se ejecutan dentro de la ventana acordada, con tu responsable de operaciones delante.

El presupuesto sale del alcance: días-persona, consultor asignado, fecha de entrega y plazo de retest. Y si lo que describes no justifica un test de intrusión —a veces lo primero que hace falta es un análisis de vulnerabilidades recurrente o una auditoría de ciberseguridad que ordene el inventario—, te lo decimos antes de presupuestar.

Entregables: informe, sesión de resultados y retest

Lo que compras no son cinco días de pruebas, sino lo que queda cuando nos vamos. Tres entregables, ninguno opcional.

El informe

Un resumen ejecutivo de dos páginas para dirección —nivel de riesgo, hallazgos principales, decisiones a tomar, sin jerga—. Después, una ficha por vulnerabilidad: descripción, criticidad CVSS y criticidad para tu proceso, que no siempre coinciden (un fallo de CVSS medio que detiene una línea es un fallo alto para ti), prueba de explotación reproducible, corrección recomendada y esfuerzo estimado. Los anexos recogen el alcance, el método y la lista de pruebas realizadas, incluidas las que no dieron resultado: suele ser la parte más útil delante de la entidad auditora. Se entrega en español, en PDF y con una tabla de seguimiento importable. La versión en inglés se incluye a petición y sin coste añadido.

La sesión de presentación de resultados

Una hora por videoconferencia o en tus instalaciones, conducida por quien ha hecho las pruebas y no por un comercial. Tu equipo de automatización, el de desarrollo y quien lleve el producto preguntan directamente, reproducimos en pantalla la explotación que haga falta y priorizamos el plan de corrección: qué se arregla en el firmware, qué se arregla en la plataforma y qué queda para la próxima revisión del hardware.

El retest

Tras tus correcciones repetimos las pruebas sobre los hallazgos identificados y emitimos un informe de retest —la contra-auditoría— que indica, hallazgo por hallazgo, qué está efectivamente cerrado y qué sigue abierto. Está incluido en el precio, sin coste añadido, dentro de los 90 días siguientes a la entrega del informe inicial: es la partida que el mercado suele facturar por jornadas. Ese documento es el que puedes pasar a un cliente, a una aseguradora o a quien te audita. Si quieres ver el formato antes de decidir, pide un informe de ejemplo anonimizado.

Tratamiento de datos y soberanía

Haxoris es una empresa establecida en la Unión Europea. Quienes realizan las pruebas trabajan desde la Unión Europea, y todo lo que un proyecto genera —capturas de tráfico de planta, imágenes de firmware, extractos de registro, notas de prueba, informes— se almacena y se respalda dentro de la Unión Europea.

El RGPD nos es directamente aplicable. Eso significa algo muy concreto para tu departamento jurídico: no hay que construir ningún mecanismo de transferencia internacional del capítulo V, ni negociar cláusulas contractuales tipo, ni apoyarse en una decisión de adecuación que un tribunal pueda anular el año que viene. Actuamos como encargado del tratamiento en el sentido del art. 28 del RGPD; la relación de subencargados y de los países en que se encuentran se te facilita antes de firmar y cualquier cambio se te notifica. Al no estar sometidos a la jurisdicción de los Estados Unidos, no nos alcanza la CLOUD Act.

Los datos del proyecto se cifran en reposo y en tránsito, solo son accesibles para las personas asignadas y se eliminan en el plazo previsto en el contrato, por defecto al vencer el plazo de retest. El informe es tuyo: no lo reutilizamos y no citamos tu nombre sin autorización escrita. En un entorno industrial esto no es una cláusula de adorno: una captura de tráfico de planta describe tu proceso productivo mejor que cualquier documento que tengas archivado, y una imagen de firmware es, literalmente, tu producto.

Si te preguntas si tiene sentido contratar pentesting fuera de España, lo hemos escrito aparte: contratar una empresa de pentesting no española.

Qué no hacemos

Decirlo es lo que hace creíble el resto.

• No certificamos. Haxoris no está acreditada por ENAC, no es entidad de certificación y no expide certificaciones de conformidad con el ENS, con la ISO/IEC 27001 ni con la serie IEC 62443. Emitimos un informe técnico de resultados; la certificación la expide un organismo de certificación acreditado y nuestro informe sirve de evidencia ante él.
• No realizamos TLPT. Las pruebas guiadas por amenazas de los arts. 26 y 27 del Reglamento (UE) 2022/2554 (DORA) se ejecutan dentro de un marco supervisado por el banco central y exigen proveedores que cumplan requisitos específicos. Un ejercicio nuestro de Red Team puede servir de preparación previa, pero no lo sustituye.
• No trabajamos con información clasificada. No disponemos de habilitación de seguridad de la Oficina Nacional de Seguridad, de modo que no intervenimos sobre sistemas que manejen información clasificada ni sobre los contenidos reservados de un Plan de Seguridad del Operador o de un Plan de Protección Específico al amparo de la Ley 8/2011 y el Real Decreto 704/2011.
• No prestamos servicios de seguridad privada. Haxoris presta servicios de seguridad informática. Esta actividad no figura entre las reservadas del art. 5.1 de la Ley 5/2014 y no requiere autorización del Ministerio del Interior. Cuando un proyecto incluye pruebas de intrusión física, se realizan sobre instalaciones del propio cliente y con autorización escrita previa.
• No tocamos sistemas instrumentados de seguridad. Los SIS y cualquier función de seguridad funcional quedan fuera de alcance por defecto: se revisan documentalmente y sobre banco de pruebas, nunca en producción.

Y algo que sí hacemos, porque suele preguntarse al revés: probamos entornos OT en producción con regularidad. No es una línea roja, es una cuestión de método —pasivo primero, intrusivo en ventana, criterio de parada acordado por escrito—.