Pentesting para ISO 27001

Objetivos: qué aporta un pentest a tu SGSI

Primera certificación, auditoría de seguimiento anual, renovación del ciclo o un cuestionario de seguridad que te ha enviado un cliente grande: siempre vuelven los mismos controles del Anexo A. Un test de intrusión es la evidencia más directa que puedes aportar para cada uno de ellos, porque demuestra funcionamiento real donde un procedimiento solo demuestra intención.

Un proyecto orientado a la ISO 27001 persigue cuatro objetivos, y conviene tenerlos separados antes de cifrar nada.

• Establecer la exposición técnica real del perímetro que cubre tu declaración de aplicabilidad, no la que se deduce del inventario.
• Producir evidencia oponible —peticiones, capturas, pasos de reproducción— en lugar de puntuaciones heredadas de una herramienta. Una auditoría rechaza un listado de escáner precisamente porque nadie lo ha validado.
• Alimentar el proceso de acciones correctivas de la cláusula 10.2 con un plan priorizado, con responsable y con fecha, en el formato que tu sistema de gestión ya consume.
• Demostrar el cierre: el retest y su acta son lo que convierte una no conformidad abierta en una no conformidad cerrada.

Haxoris está certificada en ISO/IEC 27001 por TÜV SÜD. Aplicar la norma y probar contra la norma son dos ejercicios distintos; hacemos los dos. El expediente de evidencias que te entregamos tiene la misma forma que el que presentamos a nuestra propia auditoría, lo que ahorra una discusión de formato que se repite en casi todos los proyectos.

Si lo que tienes delante es una duda de alcance más que de norma, la comparación entre probar y revisar está desarrollada en auditoría de ciberseguridad y en análisis de vulnerabilidades o pentest.

Enfoques: caja negra, caja gris y caja blanca

El enfoque describe qué sabe el equipo antes de empezar. No cambia el rigor de la prueba, sino la profundidad que obtienes con las mismas jornadas. En un contexto ISO 27001 cambia además la naturaleza de la evidencia que podrás aportar al expediente, y por eso se decide en la reunión de alcance y no sobre la marcha.

Caja negra

Sin información previa: partimos de un nombre de dominio o de un rango de direcciones IP, igual que quien ataca desde fuera y no te conoce. Responde a la pregunta «¿qué aspecto tengo visto desde internet?» y saca a la luz los activos olvidados, que es la desviación habitual sobre el control A.5.9. Su límite es mecánico y una auditoría lo conoce: lo que no se descubre, no se prueba, y el informe tiene que decirlo.

Caja gris

Una cuenta por cada rol de la aplicación y documentación funcional básica. Es el enfoque que recomendamos en la gran mayoría de proyectos ISO 27001. Reproduce el escenario más frecuente —alguien que ya dispone de credenciales, obtenidas por phishing o por reutilización de contraseñas— y garantiza que ningún rol se ha quedado fuera por falta de tiempo. Esa es exactamente la cobertura demostrable que espera el control A.8.29.

Caja blanca

Cuentas, documentación de arquitectura y acceso al código fuente. Permite remontar de un síntoma a su causa en el código, alcanzar rutas difíciles de provocar desde fuera y revisar la lógica de negocio. Es el enfoque indicado para una aplicación crítica dentro del alcance de certificación y el único que alimenta en serio los controles A.8.25 y A.8.28.

Los tres se combinan dentro de un mismo proyecto: caja negra sobre el perímetro externo para medir la exposición y, una vez levantado el mapa, caja gris sobre las aplicaciones del alcance certificado. El enfoque elegido, el perímetro y el número de jornadas quedan escritos en el presupuesto y en el acta de alcance, dos documentos que la entidad auditora puede pedirte ver.

Alcance y planificación

En un proyecto ISO 27001 el alcance no se inventa: se deriva del alcance del SGSI (cláusula 4.3) y de la declaración de aplicabilidad (cláusula 6.1.3). Una llamada de treinta a cuarenta y cinco minutos basta para dejar cerrado todo lo que sigue, y de ahí sale el presupuesto.

• Los objetivos: dominios, direcciones IP, aplicaciones, cuentas cloud y repositorios que entran, con el control del Anexo A al que cada uno sirve de evidencia.
• Las exclusiones: sistemas de terceros sin autorización del titular, filiales fuera del alcance certificado y cualquier acción descartada —denegación de servicio, ingeniería social sobre personas concretas, modificación de datos reales—. Lo que queda fuera se escribe; no se sobreentiende.
• La ventana de trabajo: fechas, franja horaria y si se prueba en horario laboral o fuera de él. Si el entorno es productivo, se pacta además el procedimiento de parada.
• Las reglas del ejercicio: intensidad admitida, tratamiento de los datos reales que aparezcan, direcciones de origen que tu equipo debe poner en lista blanca y qué hacemos ante un hallazgo crítico, que es avisarte en el momento y no esperar al informe.
• El entorno: producción o preproducción. La preproducción evita riesgo pero solo vale como evidencia si es una copia fiel de producción, y eso hay que poder sostenerlo delante de quien audita.
• Las credenciales y los accesos: una cuenta por rol, VPN si hace falta, y una persona de contacto localizable mientras dure el proyecto.

Nada empieza sin autorización por escrito y con el perímetro definido en contrato. En España el acceso no autorizado a un sistema de información está tipificado en el art. 197 bis del Código Penal y los daños informáticos en los arts. 264 y siguientes: la autorización firmada por quien tiene capacidad para darla es lo que separa un proyecto de un delito, y si el activo es de un tercero —un proveedor de alojamiento, un SaaS— hace falta también la suya.

Del acta de alcance sale un presupuesto cerrado: jornadas, enfoque, persona asignada, fecha de entrega y plazo del retest. Y si lo que nos describes no justifica un pentest —porque lo que necesitas es un análisis de vulnerabilidades recurrente o una auditoría de ciberseguridad documental—, te lo decimos antes de cifrarlo.

Entregables: informe, sesión de presentación de resultados y retest

Quien audita no busca un PDF, busca una cadena de evidencia que se cierra. Lo que compras no son jornadas, sino lo que queda después. Cuatro entregables, ninguno opcional y todos en español.

El informe

Abre con un resumen ejecutivo de dos páginas para la dirección y para quien lleva el SGSI: nivel de exposición observado, hallazgos principales y decisiones que hay que tomar, sin jerga. Después va el detalle técnico, con una ficha por hallazgo: descripción, criticidad justificada, impacto en tu negocio, pasos de reproducción, evidencia y corrección recomendada. Cada ficha indica además los controles del Anexo A a los que afecta, de forma que quien lleva el SGSI archiva el informe en el sitio correcto sin releerlo línea a línea. Los anexos recogen el alcance probado, el método seguido y —esto importa en auditoría— lo que se comprobó y salió bien.

El plan de corrección

Los hallazgos se ordenan en tres olas: lo que se corrige en días, lo que pide un proyecto trimestral y lo que es una decisión de inversión. Cada línea lleva responsable, esfuerzo estimado y fecha objetivo, que es el formato que consume tu proceso de acciones correctivas de la cláusula 10.2. Se entrega también como tabla importable a tu gestor de incidencias, para que el seguimiento viva donde ya trabaja tu equipo y no en un PDF.

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. Una parte para la dirección y otra técnica con tu equipo. Tu equipo pregunta, justificamos cada valoración y corregimos el informe si se nos había escapado un dato de contexto que cambia la criticidad. Va incluida en el precio.

El retest y el acta de verificación

Cuando despliegues las correcciones volvemos a probar los hallazgos registrados y emitimos un acta fechada que acredita qué está cerrado y qué sigue abierto. Va incluido en el precio, sin coste adicional, dentro de los 90 días siguientes a la entrega del informe. Es la partida que el mercado suele facturar aparte por jornadas y es, en un expediente ISO 27001, el documento que cierra la no conformidad: el informe inicial demuestra el problema, el acta demuestra la solución.

Qué obliga realmente en España

Aquí es donde el mercado se equivoca más: se anuncian obligaciones que todavía no existen en derecho español y se pasa por alto lo que sí está en vigor y además es literal. Esto es lo aplicable hoy, con el artículo delante.

La ISO/IEC 27001 no la impone ninguna ley española

Certificarse es voluntario. Lo que convierte la norma en obligatoria de hecho es el contrato: pliegos de licitación que la puntúan o la exigen, cuestionarios de seguridad de clientes grandes y cláusulas de cadena de suministro. Ese origen contractual tiene una consecuencia práctica que conviene aprovechar: quien te exige el certificado suele exigir también la evidencia técnica que hay detrás, y es más barato producir las dos cosas a la vez que dos veces.

Conviene añadir una precisión que en España se confunde a menudo: un certificado de la ISO/IEC 27001 no acredita la conformidad con el ENS. Son marcos distintos, con alcances y controles distintos, y el Centro Criptológico Nacional publica sobre esa correspondencia la guía pública CCN-STIC 825. Lo que sí ocurre es que buena parte del trabajo técnico sirve para los dos expedientes.

El ENS: Real Decreto 311/2022

Si tu organización presta servicios al sector público, el Esquema Nacional de Seguridad pesa más que la ISO y no deja margen de interpretación. El art. 31 somete los sistemas a una auditoría regular ordinaria al menos cada dos años, y el art. 38 separa los dos caminos de conformidad: autoevaluación para categoría BÁSICA y certificación para MEDIA y ALTA.

En el Anexo II, el refuerzo R6 del control [op.mon.3] desarrolla la 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. Traducido: tu proveedor cloud puede obligarte a encargar pruebas técnicas aunque tu sistema sea BÁSICA. Está desarrollado en qué exige realmente el ENS sobre pentesting y en quién puede auditar el ENS.

NIS2 todavía no es derecho español

La Directiva (UE) 2022/2555 debía estar transpuesta el 17 de octubre de 2024. En España, 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; el 9 de julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la UE por esa falta de transposición, procedimiento INFR(2024)0270. Quien te venda hoy una certificación «de cumplimiento NIS2 en España» te está vendiendo un texto que aún no existe.

Lo que sí obliga ahora mismo es lo anterior: el Real Decreto-ley 12/2018 y su reglamento de desarrollo, el Real Decreto 43/2021. Y una pieza que no depende de ninguna ley española, porque es un reglamento y se aplica de forma directa: el Reglamento de Ejecución (UE) 2024/2690, cuyo Anexo, en el punto 6.5 «Pruebas de seguridad», exige una política de pruebas documentada, un alcance y una frecuencia fijados en función del riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. Si tu entidad presta servicios en la nube, centros de datos, redes de distribución de contenidos, servicios gestionados o de seguridad gestionados, mercados en línea, motores de búsqueda, plataformas de redes sociales o servicios de confianza, esa obligación ya te alcanza, tengas o no el certificado de la ISO. Más detalle en pentesting para NIS2, en NIS2 en España: qué obliga hoy y qué no y, para el solape entre ambos marcos, en ISO 27001 y NIS2: qué cambia en España.

RGPD

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». Un pentest periódico y documentado es la forma más directa de sostener ese artículo, y por eso el informe recoge alcance, fechas, método, hallazgos y qué se volvió a comprobar después de corregir: es el expediente que se enseña ante la AEPD, y el mismo que archiva quien te certifica.

DORA y el sector financiero

El Reglamento (UE) 2022/2554 se aplica desde el 17 de enero de 2025. Sus arts. 24 y 25 obligan a 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 exigen proveedores que cumplan el art. 27 del propio reglamento y no son un servicio que prestemos; lo decimos más abajo, con todas las letras.

Última revisión: 12 de septiembre de 2026. Esta sección cita normas en evolución; si una cambia, la corregimos aquí.

Lo que no hacemos

En un proyecto de certificación, la frontera importa tanto como el servicio: decirla en voz alta es lo que hace creíble el resto de la página. Hay cuatro cosas que en España no podemos ofrecerte.

• Probamos, no certificamos. Haxoris no es organismo de certificación y no está acreditada por ENAC. No expedimos el certificado de la ISO/IEC 27001, ni certificados de conformidad con el ENS, ni el Distintivo de Conformidad del ENS. Producimos la prueba técnica y el expediente de evidencias en los que se apoya la entidad que sí los emite, y la revisión previa al paso ante ella.
• No realizamos TLPT. Los ejercicios guiados por amenazas del marco TIBER-ES, coordinado por el Banco de España, exigen proveedores que cumplan el art. 27 del Reglamento (UE) 2022/2554. 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 exige 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 a partir de fuentes abiertas se limita a la superficie de exposición de la organización, dentro del alcance contratado y sin investigar a personas concretas.

Y una quinta, menos jurídica: tampoco implantamos lo que hemos encontrado. Te acompañamos, resolvemos dudas de tu equipo y volvemos a comprobar el resultado, pero no vendemos la corrección de nuestros propios hallazgos. Esa separación es justo lo que hace que el informe valga algo delante de quien te audita.

Tratamiento de datos y soberanía

Un pentest genera material sensible: capturas, volcados de configuración, credenciales de prueba, a veces fragmentos de código. Y hay una vuelta de tuerca propia de la ISO 27001 que conviene ver venir: al contratarnos entramos en tu registro de proveedores, así que los controles A.5.19 a A.5.23 del Anexo A se aplican a nosotros y tu entidad auditora los revisará. Esta sección está escrita para que esa ficha de proveedor puedas rellenarla sin llamarnos.

Haxoris es una empresa establecida en la Unión Europea, con oficinas en Bratislava y Praga. El equipo trabaja desde la Unión Europea y todo lo que se genera durante el proyecto se almacena y se respalda en la Unión Europea.

La consecuencia se nota 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 sus países 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.

Las evidencias van cifradas en reposo y en tránsito, solo acceden a ellas las personas asignadas a tu proyecto y se borran en el plazo pactado en el contrato, por defecto al vencer el plazo del retest. El informe es tuyo: no lo reutilizamos y no citamos tu nombre sin autorización por escrito.

Si la duda de fondo es si tiene sentido contratar esto fuera de España, la respondemos con números y con derecho aplicable en contratar una empresa de pentesting no española, y los criterios de selección de proveedor están en cómo elegir una empresa de pentesting.