Directiva (UE) 2022/2555
Pentesting para NIS2
La Directiva (UE) 2022/2555 exige a las entidades esenciales e importantes medidas de gestión de riesgos y, en su art. 21.2.f), políticas y procedimientos para evaluar la eficacia de esas medidas. Toda la dificultad está en ese verbo. Un test de intrusión es la forma más directa de producir esa evaluación: no describe tus medidas, las pone a prueba.
En España la directiva todavía no está transpuesta, así que nadie puede venderte hoy «cumplimiento NIS2». Lo que sí podemos hacer es probar aquello que la directiva manda evaluar y entregarte un informe en español que tu equipo técnico, tu dirección y quien te audite puedan leer. El retest que verifica las correcciones va incluido.
Estado jurídico
NIS2 en España: dónde está la transposición
Situación a 12 de septiembre de 2026: la Directiva (UE) 2022/2555 debía estar transpuesta el 17 de octubre de 2024 y en España sigue sin estarlo. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad tuvo su 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 llevó a España ante el Tribunal de Justicia de la Unión Europea por esa falta de transposición, en el procedimiento INFR(2024)0270.
Qué significa esto para ti, en concreto: hoy no hay registro nacional de entidades NIS2, ni plazo español, ni clasificación oficial como entidad esencial o importante, ni cuantía de sanción que alguien pueda presentarte como derecho vigente. Si una página te anuncia multas «de hasta el 10 % de la facturación» en España, está describiendo un texto que todavía no se ha escrito. Trabajamos por tanto en anticipación: probamos lo que la directiva pide evaluar, sin venderte la conformidad con una ley sin publicar. El recorrido parlamentario lo seguimos en NIS2 en España: qué obliga hoy y qué no.
Última revisión: 12 de septiembre de 2026.
Confían en nosotros
Qué obliga realmente en España
Que NIS2 no sea todavía derecho español no significa que no tengas obligaciones de prueba. Significa que están escritas en otros textos, y tres de ellos se aplican sin esperar a ninguna ley nacional. Esto es lo que hay, con el artículo delante.
Lo que está en vigor: RDL 12/2018 y RD 43/2021
La generación anterior de la norma sigue plenamente vigente. El Real Decreto-ley 12/2018, de seguridad de las redes y sistemas de información, y su reglamento de desarrollo, el Real Decreto 43/2021, obligan a los operadores de servicios esenciales y a los proveedores de servicios digitales a adoptar medidas técnicas y organizativas y a notificar los incidentes. Mientras el anteproyecto no se convierta en ley, ese es el marco que se te aplica, y no NIS2.
Reglamento de Ejecución (UE) 2024/2690: aquí sí hay una obligación de probar
Es la pieza que casi nadie cita y la que más te puede afectar. Al ser un reglamento, se aplica de forma directa y no necesita transposición: está en vigor en España hoy. Desarrolla las medidas del art. 21.2 de la directiva para un grupo concreto de entidades —proveedores de servicios DNS, registros de nombres de dominio de primer nivel, proveedores de servicios de computación en nube, de centros de datos y de 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.
Su Anexo, en el punto 6.5 «Pruebas de seguridad», no deja mucho margen de interpretación. Hay que establecer y mantener una política y unos procedimientos de pruebas de seguridad documentados; fijar el alcance y la frecuencia en función del riesgo; ejecutar las pruebas con una metodología documentada; dejar constancia de los resultados; y corregir las vulnerabilidades críticas que se detecten. Si tu entidad figura en esa lista, ya tienes una obligación de pruebas de seguridad, esté publicada o no la ley española.
El ENS es lo que más pesa hoy
Si prestas servicios al sector público, o eres proveedor de quien los presta, el Esquema Nacional de Seguridad te llegará antes que NIS2. El art. 31 del RD 311/2022 somete los sistemas de categoría MEDIA y ALTA a una auditoría regular ordinaria al menos cada dos años, y el art. 38 separa los dos caminos de conformidad: autoevaluación en categoría BÁSICA y certificación en MEDIA y ALTA.
En el Anexo II, el refuerzo R6 del control [op.mon.3] desarrolla el ciclo de supervisión continua y su subrequisito [op.mon.3.r6.3] se titula literalmente «Pruebas de penetración» para categoría ALTA. Hay además una puerta menos conocida: op.nub.1.2 a) exige, ya desde categoría BÁSICA, una «Auditoría de pruebas de penetración (pentesting)» cuando el servicio en la nube lo presta un tercero que no acredita conformidad con el ENS. Es decir, tu proveedor cloud puede obligarte a encargar un pentest aunque tu propio sistema sea BÁSICA.
Lo que aportamos es la prueba técnica que alimenta esa auditoría. La conformidad la declara o la certifica quien corresponde: Haxoris no está acreditada por ENAC, no es entidad de certificación y no expide ni el certificado de conformidad con el ENS ni el Distintivo de Conformidad. Lo desarrollamos en qué exige realmente el ENS sobre pentesting.
RGPD: la obligación de probar que ya tienes
El art. 32.1.d) del Reglamento (UE) 2016/679 incluye entre las medidas apropiadas «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». Es la base jurídica más directa de un test de intrusión periódico y no depende de ninguna transposición. Por eso documentamos cada proyecto de forma que el informe aguante delante de la AEPD o de quien te audite: alcance, fechas, hallazgos, criticidad y qué se volvió a probar después de corregir.
DORA, si eres una entidad financiera
El Reglamento (UE) 2022/2554 se aplica desde el 17 de enero de 2025 y, para banca, seguros, pagos, gestión de activos y sus proveedores críticos de servicios TIC, desplaza buena parte de la conversación sobre NIS2. Sus arts. 24 y 25 obligan a mantener un programa de pruebas de resiliencia digital, y el art. 26 añade, para las entidades que designe la autoridad competente, ejercicios TLPT al menos cada tres años. Esos ejercicios los ejecutan proveedores que cumplen el art. 27, y no son un servicio que prestemos: lo decimos con todas las letras más abajo.
Por urgencia real, el orden es este: primero lo que ya se te aplica —RGPD siempre, y después ENS o DORA según quién seas—; luego el Reglamento de Ejecución (UE) 2024/2690 si tu entidad está en su lista; y NIS2 como horizonte que conviene tener trabajado antes de que llegue. Quien empiece probando en lugar de documentando llegará a la transposición con correcciones desplegadas y no con un plan de acción, que es la única ventaja que no se recupera en tres meses.
Artículo 21.2 de la directiva → qué entregamos
Cada fila remite al texto europeo, que en España sigue pendiente de transposición: son objetivos que conviene anticipar, no obligaciones españolas en vigor.
| Medida del art. 21.2 | Qué entrega Haxoris |
|---|---|
| Art. 21.2.e) — seguridad en la adquisición, el desarrollo y el mantenimiento de los sistemas, incluidas la gestión y la divulgación de vulnerabilidades | Pentesting de aplicaciones y API y auditoría de infraestructura según el OWASP Top 10, la guía WSTG y el ASVS. Cada hallazgo lleva criticidad, evidencia de explotación reproducible y una corrección con el esfuerzo estimado. |
| Art. 21.2.f) — políticas y procedimientos para evaluar la eficacia de las medidas de gestión de riesgos | Una prueba independiente que mide si los controles que ya pagas detienen de verdad a un atacante, más el retest incluido que acredita el cierre. El bucle completo, no solo el hallazgo inicial. |
| Art. 21.2.d) — seguridad de la cadena de suministro | Pruebas sobre las integraciones, las API y los componentes de terceros de los que depende tu servicio: configuración cloud, fronteras de identidad, accesos abiertos a proveedores y cadena de construcción del software. |
| Art. 21.2.i) y j) — higiene informática básica, criptografía y autenticación multifactor | Verificación ofensiva de los cimientos: política de contraseñas, elusión del doble factor, interfaces de administración expuestas, cifrado en tránsito y en las copias de seguridad, cuentas de servicio olvidadas en Active Directory. |
| Art. 21.2.g) — prácticas de ciberhigiene y concienciación en ciberseguridad | Campañas de phishing simulado y test de ingeniería social, con resultados siempre agregados y nunca nominativos, más sesiones de concienciación para tu equipo. |
| Art. 23 — notificación de incidentes | Los hallazgos cuya explotación constituiría un incidente significativo se señalan como tales en el informe. Ensayas una vez la cadena de alerta —24 horas, 72 horas, un mes— antes de necesitarla de verdad. |
Estas exigencias son las de la directiva europea. Las obligaciones que acaben aplicándose en España saldrán del texto de transposición, hoy sin aprobar. No somos autoridad de control ni entidad de certificación y no emitimos juicios de conformidad: aportamos la demostración técnica.
¿A quién afecta NIS2?
La directiva cubre dieciocho sectores y distingue dos categorías: entidades esenciales y entidades importantes. La categoría cambia sobre todo la intensidad de la supervisión, mucho menos el contenido técnico de las medidas que se esperan.
Los umbrales, la clasificación definitiva y el procedimiento de registro dependerán de la ley española de transposición, que sigue sin aprobarse. No determinamos tu clasificación y no sustituimos a ninguna autoridad. Un matiz que importa: si eres proveedor de entidades de estos sectores, el asunto también te afecta por la cadena de suministro, y normalmente te llega por contrato mucho antes que por ley.
Tipos de prueba y alcances habituales
Una preparación no se juega en un único proyecto. Según tu exposición y los servicios que tengas que sostener, combinamos dos o tres de estas pruebas; la planificación decide y el presupuesto sigue al alcance elegido.
Si lo que necesitas es una fotografía amplia y recurrente en lugar de una prueba profunda, el análisis de vulnerabilidades cubre mucha más superficie sin explotación; la diferencia está desarrollada en análisis de vulnerabilidades o pentest.
Enfoques: caja negra, caja gris y caja blanca
El enfoque describe lo que el equipo sabe antes de empezar. No cambia el realismo de la prueba, sino la profundidad que se consigue con el mismo presupuesto y, en un expediente de preparación ante NIS2, la naturaleza de la evidencia que produces.
Caja negra
Ninguna información previa: un nombre de dominio o un rango de direcciones IP, como un atacante desde fuera. Responde a la pregunta «¿qué aspecto tengo visto desde internet?» y hace aflorar los activos olvidados: entornos de preproducción accesibles, paneles de administración publicados, restos de un proyecto antiguo. Su límite es mecánico —lo que no se descubre no se prueba—, y por eso como evidencia frente al art. 21.2.e) queda incompleta.
Caja gris
Una cuenta por rol de la aplicación y algo de documentación funcional. Es el enfoque que recomendamos en la gran mayoría de las preparaciones: reproduce el escenario que de verdad ocurre —alguien que ya dispone de acceso, obtenido por phishing, por la cuenta de un proveedor o por una contraseña reutilizada— y cubre todos los roles dentro de las jornadas contratadas. Es también el que mejor se lee desde fuera, porque la cobertura queda explícita.
Caja blanca
Cuentas, esquemas de arquitectura, configuraciones y, cuando procede, código fuente. Subimos del síntoma a la causa en lugar de quedarnos en el hallazgo. Es el enfoque indicado para los sistemas que sostienen un servicio esencial, para los componentes desarrollados en casa y para una arquitectura recién rehecha. Es el que más preparación te exige y el que más profundidad devuelve por jornada comprada.
La directiva no impone ninguno de los tres: la elección se hace en la planificación, en función de lo que tengas que demostrar. Después queda escrita en el informe, porque quien lo lea desde fuera necesita saber qué sabía el equipo al empezar para interpretar bien lo que encontró.
Nuestra metodología: cómo se desarrolla el proyecto
Los proyectos siguen un recorrido estable, apoyado en el PTES para la conducción y en las guías de OWASP para el contenido —el WSTG para web, el MASTG para móvil y el ASVS para verificar requisitos—: nuestras metodologías en detalle. Sobre esa base, cada hallazgo queda enlazado con la medida del art. 21.2 que pone en cuestión.
Planificación y diagnóstico de partida (scoping)
De media jornada a dos: confrontamos las medidas del art. 21.2 con tu inventario real, localizamos los sistemas que sostienen los servicios más expuestos y nos quedamos con las pruebas que aportan evidencia en lugar de una línea más en un cuestionario. Sales con un alcance cifrado en jornadas y en euros.
Autorización por escrito (rules of engagement)
Nada empieza sin mandato firmado: objetivos, exclusiones, ventana de ejecución, profundidad de explotación autorizada y qué hacemos ante un hallazgo crítico —te avisamos en el momento, sin esperar al informe—. Ese documento es lo que hace lícita la prueba frente a los arts. 197 bis y 264 del Código Penal, y lo que abre el expediente de evidencias.
Reconocimiento y cartografía (information gathering)
Inventariamos lo que está expuesto y es alcanzable: subdominios, servicios, tecnologías, puntos de entrada de API, dependencias de proveedores e información pública aprovechable. Sale de ahí un mapa del alcance y una lista de escenarios de ataque plausibles que validamos contigo antes de seguir.
Pruebas manuales y explotación (exploitation)
Las herramientas sirven para cubrir el alcance; los hallazgos que importan salen de encadenar a mano defectos aislados: un control de acceso que falta, un token mal verificado, una clave olvidada en un repositorio. La explotación se detiene en cuanto el impacto queda demostrado, nunca más allá.
Informe y plan de remediación (reporting)
Cada hallazgo va fechado, ilustrado, priorizado y enlazado con la medida del art. 21.2 que incumple, con una corrección concreta y un esfuerzo estimado. Así el informe se convierte en una lista de trabajo asignable a personas y no en un documento de archivo.
Resultados y retest (retest)
Una hora con la persona que ha hecho las pruebas y, después de tus correcciones, un retest incluido dentro de los 90 días que acredita el cierre de cada vulnerabilidad. Ese último documento es el que cierra el bucle que pide el art. 21.2.f).
Alcance y planificación
La planificación decide el valor de un proyecto mucho más que el número de jornadas vendidas. Ocupa alrededor de una hora y deja cerrado lo siguiente.
- Los objetivos: direcciones URL, rangos de direcciones IP, cuentas por rol, suscripciones cloud, segmentos de red industrial y, si procede, repositorios de código.
- Las exclusiones: sistemas de terceros, entornos fuera de alcance, denegación de servicio y cualquier acción destructiva. En entornos OT, además, todo lo que pueda tocar la disponibilidad del proceso.
- La ventana de ejecución y una persona de contacto localizable por tu parte mientras dure el proyecto.
- Las reglas de enfrentamiento: hasta dónde se autoriza explotar, cómo se tratan los datos reales y qué hacemos ante un hallazgo crítico.
- El entorno: preproducción equivalente a producción cuando existe y, si no existe, producción con precauciones reforzadas y ventanas de baja actividad.
- La trazabilidad: qué medida del art. 21.2, qué punto del Reglamento (UE) 2024/2690 o qué control del ENS debe quedar cubierto, para que el informe se pueda leer después como evidencia y no solo como una lista técnica.
Si la aplicación está alojada en un tercero, pedimos también la conformidad del proveedor de alojamiento durante la planificación. Y si eres proveedor de una entidad de los sectores de la directiva, trae el anexo de seguridad que te ha mandado tu cliente: en la mayoría de los casos el alcance que necesitas ya está escrito ahí, y de ello sale un proyecto más corto y más barato que el genérico.
El presupuesto sale de esa planificación: jornadas, persona asignada, fecha de entrega y plazo de retest, en 24 horas laborables. Y si lo que nos describes no justifica un test de intrusión, te lo decimos antes de cifrarlo.
Entregables: informe, sesión de resultados y retest
Lo que compras no es una semana de pruebas, sino lo que queda después —y, en una preparación ante NIS2, lo que siga siendo legible dentro de dieciocho meses ante alguien que no estuvo en la sala. Cuatro entregables, ninguno opcional y todos en español.
El informe
Un resumen ejecutivo de dos páginas para la dirección: nivel de riesgo, hallazgos principales y decisiones que hay que tomar, sin jerga. Es el formato que necesita un órgano de dirección al que el art. 20 de la directiva hace responsable de aprobar y supervisar las medidas. Después, una ficha por vulnerabilidad con la descripción, la criticidad CVSS y la criticidad de negocio, la evidencia de explotación reproducible, la corrección recomendada, el esfuerzo estimado y la medida del art. 21.2 afectada. Los anexos recogen el alcance, la metodología y la lista de pruebas realizadas, incluidas las que no dieron resultado: suele ser la parte más útil delante de quien audita. Se entrega en PDF, con una tabla de seguimiento importable.
La sesión de presentación de resultados
Una hora por videoconferencia, dirigida por la persona que ha hecho las pruebas y no por un comercial. Tu equipo de desarrollo pregunta, reproducimos en pantalla la explotación que haga falta y priorizamos juntos el plan de corrección. Cuando el asunto sube al comité de dirección, reservamos una segunda sesión más corta para ese público.
El retest
Después de tus correcciones repetimos las pruebas sobre las vulnerabilidades identificadas y emitimos un informe de retest que acredita qué queda cerrado y qué no. Va incluido en el precio, sin coste adicional, dentro de los 90 días siguientes a la entrega del informe inicial. Es el único documento que demuestra que una medida correctora funciona, y es justamente el que más falta en los expedientes que nos llegan.
El expediente de evidencias
Mandato firmado, nota de alcance, informe, plan de remediación y acta de retest forman un conjunto fechado y coherente. No expedimos certificados ni declaraciones de conformidad: no somos autoridad ni entidad de certificación. Ese expediente es la parte técnica que podrás presentar el día que la transposición española fije tus obligaciones, y la que tus clientes ya te están pidiendo hoy.
¿Por qué Haxoris?
La oferta española en torno a NIS2 es casi toda consultoría y gobernanza. Es útil, pero no te dice si tus medidas aguantan. Esa es la otra mitad del trabajo, y es la que hacemos nosotros. Esto es lo que ponemos encima de la mesa.
Certificaciones del equipo
Retest incluido, sin coste añadido:
Verificar las correcciones forma parte del proyecto, dentro de los 90 días posteriores al informe, y termina en un documento que acredita el cierre de cada vulnerabilidad. Es la pieza que cierra el bucle del art. 21.2.f) y la que el mercado suele facturar aparte.
Sabes qué vas a pagar:
Damos horquillas de precio y la unidad de medida, la jornada de consultoría, antes de la primera reunión. Una preparación habitual son 8 a 20 jornadas. Comparas con cifras y no con impresiones.
Sabes quién prueba:
El nombre, la trayectoria y las certificaciones de la persona asignada se te comunican antes de firmar, y es la misma que dirige la sesión de resultados.
Proveedor europeo:
Haxoris es una empresa establecida en la Unión Europea, con oficinas en Bratislava y Praga. El equipo interviene desde la Unión, los datos del proyecto se guardan aquí y el RGPD se nos aplica de forma directa: no hay mecanismo de transferencia que construir.
Testimonios
Lo que dicen nuestros clientes
Lo que no hacemos
Decirlo en voz alta es lo que hace creíble el resto de la página. En materia de NIS2 hay cinco cosas que no vamos a ofrecerte, y ninguna se arregla con una frase ambigua.
- No declaramos tu clasificación. Nadie puede decirte hoy con carácter oficial si serás entidad esencial o entidad importante en España: eso saldrá de la ley de transposición y de la autoridad que se designe. Podemos repasar contigo los sectores de la directiva, tus umbrales de plantilla y facturación y tu posición como proveedor, pero no sustituimos a nadie.
- No certificamos. No somos entidad de certificación acreditada por ENAC y no expedimos certificados de conformidad con el ENS, el Distintivo de Conformidad ni certificados ISO 27001. Emitimos un informe técnico de resultados que te sirve de evidencia ante el organismo que sí certifica, y trabajamos junto a la entidad auditora que elijas.
- No realizamos TLPT. Los ejercicios de pruebas guiadas por amenazas del marco TIBER-ES, coordinado por el Banco de España, exigen proveedores que cumplan el art. 27 de DORA. Un ejercicio de Red Team nuestro puede servirte de preparación previa, pero no lo sustituye.
- No trabajamos con información clasificada. El acceso a esa información requiere habilitación de seguridad de la Oficina Nacional de Seguridad; no la tenemos y no nos presentamos a esos pliegos.
- No somos una empresa de seguridad privada. Prestamos 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. Nuestro reconocimiento OSINT se limita a la superficie de exposición de la organización a partir de fuentes abiertas, dentro del alcance contratado y sin investigar a personas concretas.
Y una sexta, menos jurídica: no prometemos dejarte «conforme con NIS2». Un proyecto te deja una lista priorizada, unas evidencias fechadas y la prueba de que lo corregido está corregido. Cuando llegue la ley española, eso es exactamente lo que te van a pedir enseñar.
Tratamiento de datos y soberanía
Haxoris es una empresa establecida en la Unión Europea, con oficinas en Bratislava y Praga. El equipo interviene desde la Unión Europea y todo lo que se genera durante un proyecto —capturas, extractos de registros, notas de prueba, informes— se almacena y se respalda en la Unión Europea.
La consecuencia práctica aparece en cuanto tu departamento jurídico abre el contrato: el RGPD se nos aplica de forma directa, así que no hay transferencia internacional del capítulo V que justificar, ni cláusulas contractuales tipo que negociar, ni evaluación de impacto de transferencias que redactar. Actuamos como encargado del tratamiento en el sentido del art. 28 y el contrato lo recoge; la relación de subencargados y los países donde operan se te comunica antes de firmar, y cualquier cambio se te notifica. Al no estar sujetos a la jurisdicción de Estados Unidos, no nos alcanza la CLOUD Act.
En una conversación sobre NIS2 esto no es un detalle menor. El art. 21.2.d) de la directiva sitúa la seguridad de la cadena de suministro entre las medidas exigibles, y tú eres para tus clientes exactamente lo que tus proveedores son para ti. Un proveedor de pruebas establecido en la Unión es una línea menos que justificar en tu propio expediente y una pregunta menos en el cuestionario de seguridad que te manda tu cliente del sector.
Los datos de prueba van cifrados en reposo y en tránsito, solo acceden a ellos las personas asignadas a tu proyecto y se borran en el plazo pactado en el contrato, por defecto al vencer el plazo de retest. El informe es tuyo: no lo reutilizamos y no mencionamos tu nombre sin tu autorización por escrito.
Si la duda es si tiene sentido contratar pentesting fuera de España, la respondemos con números y con derecho aplicable en contratar una empresa de pentesting no española.
Preguntas frecuentes
01 ¿NIS2 obliga a hacer un test de intrusión?
Por su nombre, no. El art. 21.2 de la directiva enumera medidas —análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, higiene informática, criptografía, autenticación multifactor— y su letra f) pide políticas y procedimientos para evaluar la eficacia de esas medidas. El test de intrusión es la manera habitual de producir esa evaluación, no una obligación designada por el texto.
Donde sí hay una obligación escrita de probar es en el Reglamento de Ejecución (UE) 2024/2690, cuyo Anexo, en el punto 6.5, exige a las entidades digitales que enumera 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. Y en el art. 32.1.d) del RGPD, que pide «un proceso de verificación, evaluación y valoración regulares». Si lees por ahí que NIS2 impone un pentest anual en España, eso no está ni en la directiva ni, a día de hoy, en ninguna norma española.
02 ¿Nos afecta NIS2?
Depende de tu sector, de tu tamaño y, en último término, de la ley española de transposición, que no está aprobada. No determinamos tu clasificación ni la anunciamos en lugar del legislador: hoy nadie puede hacerlo honestamente.
Lo que sí podemos hacer ya: repasar contigo los dieciocho sectores de la directiva, tus umbrales de plantilla y facturación y, sobre todo, tu posición como proveedor. Muchas organizaciones reciben sus primeros requisitos NIS2 por contrato, de un cliente afectado, bastante antes de que exista obligación legal. Cuéntanos qué operas; la conversación de alcance es gratuita y sin compromiso.
03 ¿Cuánto cuesta prepararse?
El precio sigue al alcance, nunca a las siglas. Un test de intrusión de una aplicación web arranca alrededor de 2.500 €. Una preparación completa —diagnóstico de partida, prueba externa, prueba interna, una aplicación de negocio y el retest incluido— suele situarse entre 5.000 y 20.000 €.
Damos las horquillas antes de la primera reunión y, tras una planificación de media hora, recibes un presupuesto cerrado y desglosado por jornadas. El cálculo está detallado en cuánto cuesta un pentest en España.
04 ¿Cuántas jornadas hay que prever?
El diagnóstico de partida son 1 a 3 jornadas. Una prueba externa sobre el perímetro de una pyme o una mediana empresa, 3 a 5. Una prueba interna con Active Directory, 5 a 10. Una aplicación de negocio, 5 a 15 según el número de roles, de API y de recorridos que haya que cubrir.
Una preparación habitual suma por tanto 8 a 20 jornadas, repartidas en cuatro a seis semanas. Preferimos vender menos jornadas sobre un alcance ajustado que lo contrario: una prueba estirada sobre demasiada superficie no demuestra nada y cuesta lo mismo.
05 ¿Nos vale la ISO 27001 que ya tenemos?
Ayuda mucho, y no basta. Un sistema de gestión de la seguridad de la información cubre buena parte de las medidas del art. 21.2 —análisis de riesgos, continuidad, gestión de incidentes, proveedores—, pero la directiva añade obligaciones de notificación con plazos propios y una responsabilidad directa del órgano de dirección que la norma ISO no impone. La articulación de los dos marcos está desarrollada en ISO 27001 y NIS2: qué cambia en España, y las pruebas que alimentan tu sistema de gestión, en pentesting para ISO 27001.
06 ¿Hace falta un proveedor acreditado?
No para un proyecto que contrata una empresa privada. En España no existe una acreditación obligatoria para prestar servicios de pentesting. Las acreditaciones importan en caminos concretos —la certificación del ENS, que expide una entidad acreditada por ENAC, o los ejercicios TLPT del sector financiero— y no en un contrato ordinario de seguridad ofensiva. No estamos acreditados por ENAC y no lo insinuamos. Lo que ponemos delante se puede comprobar antes de firmar: el nombre y las certificaciones de quien prueba, un informe de ejemplo y el retest incluido. Ampliado en cómo elegir una empresa de pentesting.
07 ¿Puede la prueba afectar a producción?
El riesgo nunca es cero, pero se controla. Las acciones destructivas y las pruebas de denegación de servicio quedan excluidas por defecto, la explotación se detiene en cuanto el impacto está demostrado y, durante la ventana acordada, hay una persona localizable por cada parte. Cuando existe una preproducción equivalente, trabajamos allí primero; en entornos OT, cualquier prueba que pueda tocar la disponibilidad del proceso se acuerda una a una.
08 ¿Sirve el informe ante una autoridad o ante un cliente que nos audita?
Sirve como evidencia técnica, que es lo que se te va a pedir. El informe documenta alcance, metodología, hallazgos, criticidad, corrección recomendada y verificación posterior, con la trazabilidad hacia la medida del art. 21.2, el punto del Reglamento (UE) 2024/2690 o el control del ENS que corresponda. No es una declaración de conformidad y no la sustituye: esa la hace tu organización, o la certifica quien está acreditado para ello. Si además quieres preparar la revisión completa, mira la auditoría de ciberseguridad.
