Seguridad ofensiva

Pentest o análisis de vulnerabilidades: qué te están pidiendo de verdad

Te piden una "auditoría de seguridad", pides tres presupuestos y recibes tres cifras que no se parecen en nada. No es que unos sean caros: es que te ofrecen servicios distintos. Esta guía aclara qué cubre cada uno, quién exige qué y en qué orden resolverlo.

Llega un correo de tu cliente principal con un cuestionario de seguridad adjunto. La casilla 14 pide "evidencia de test de intrusión de los últimos 12 meses". Pides presupuesto a tres proveedores y recibes tres cifras que no se parecen en nada: una de 900 euros, otra de 4.500 y otra de 12.000. Los tres documentos se titulan "auditoría de seguridad".

No es que uno sea caro y los otros baratos. Es que te están ofreciendo servicios distintos, y probablemente solo uno responde a lo que te han pedido.

Llevo más de veinte años en ciberseguridad y esta confusión la veo cada mes en pymes de Navarra y de todo el país. Y voy a ser claro: buena parte de la culpa la tiene mi propio sector, que lleva años vendiendo escaneos automáticos con la palabra "pentest" en la portada porque suena mejor y se cobra más caro.

Dos servicios distintos que todo el mundo llama igual

Un análisis de vulnerabilidades es, en esencia, una revisión automatizada. Una herramienta recorre tus sistemas y los compara contra una base de datos de fallos conocidos: versiones sin parchear, configuraciones inseguras, servicios expuestos que no deberían estarlo. El resultado es un listado amplio de debilidades ordenado por gravedad. Es rápido, relativamente económico y se puede repetir cada mes.

Un test de intrusión, el famoso pentest, es otra cosa. Aquí hay una persona con las mismas técnicas que usaría un atacante intentando entrar de verdad. No se limita a listar puertas mal cerradas: elige una, la abre y comprueba hasta dónde llega. Encadena fallos que por separado parecen menores y termina demostrando impacto real: "he llegado a la base de datos de clientes" o "he conseguido permisos de administrador del dominio".

La forma más corta de explicarlo: el análisis de vulnerabilidades te dice qué cerraduras están flojas; el pentest paga a alguien de confianza para que intente entrar en tu casa y luego te cuente, paso a paso, cómo lo ha conseguido. Un matiz que importa: un pentest serio incluye una fase de análisis de vulnerabilidades dentro de su metodología, pero lo contrario no ocurre nunca. De ahí la señal de alarma más fiable que conozco: si el "pentest" que te ofrecen es un PDF exportado de un escáner con el logo cambiado, sin evidencias de explotación ni narrativa de ataque, no es un pentest.

Si lo que quieres es la comparación completa de los servicios ofensivos, incluido el red team y cuál encaja con tu madurez, la desarrollamos en pentesting, análisis de vulnerabilidades y red team. Aquí vamos a lo otro, lo que casi nadie te explica: qué te están pidiendo de verdad y en qué orden conviene resolverlo.

Quién te lo pide y qué significa en cada caso

La respuesta correcta depende menos de la técnica y más de quién firma el requisito. Estos son los casos que nos llegan a diario.

El auditor de ISO 27001. El control 8.8 de la norma (gestión de vulnerabilidades técnicas) exige un proceso continuo: identificar, evaluar y corregir. Un pentest anual, por sí solo, no cubre ese "continuo". Pero la norma también espera que compruebes que tus defensas funcionan (el control 8.29 pide pruebas de seguridad en desarrollo y aceptación), y un pentest periódico es la evidencia que menos discusión genera en auditoría. En la práctica: necesitas las dos piezas, con pesos distintos.

El ENS, si trabajas para la Administración. El Real Decreto 311/2022 exige mantenimiento y actualizaciones de seguridad continuas en la operación (medida op.exp.4) y, según la categoría del sistema, análisis de vulnerabilidades y pruebas de penetración antes de la puesta en servicio (medida mp.sw.2 del Anexo II). Si eres proveedor tecnológico de una entidad pública, esto te aplica aunque tu empresa sea privada. Lo vemos constantemente en proyectos de adecuación al ENS de proveedores que descubren el requisito en mitad de una licitación.

El cuestionario de tu cliente de automoción. TISAX y los formularios de compras del sector suelen preguntar por las dos cosas: proceso de gestión de vulnerabilidades y pruebas de intrusión periódicas sobre lo que está expuesto. Responder que sí sin tenerlo montado es hipotecar la siguiente auditoría de cliente.

La aseguradora del ciberseguro. Los cuestionarios de contratación preguntan cada vez más por escaneos externos y, en pólizas de cierto tamaño, por pentest. Cuidado con esto: si declaras que haces pruebas anuales y no las haces, ese papel aparecerá el día del siniestro.

NIS2. La directiva no nombra el pentest. Lo que pide su artículo 21 son políticas y procedimientos para evaluar la eficacia de las medidas de seguridad. En la práctica, demostrar esa eficacia sin pruebas técnicas es complicado, y así lo estamos viendo en los primeros proyectos de adecuación a NIS2. La transposición española sigue su curso, con el Real Decreto-ley 7/2025 como primer paso, así que la letra pequeña todavía puede moverse.

Sea cual sea tu caso, el truco es siempre el mismo: pide por escrito la frase exacta del requisito y exige que la oferta responda a esa frase, no a la interpretación del comercial.

Los errores que nos encontramos una y otra vez

El primero ya lo conoces: presentar un escaneo como pentest. El auditor o el cliente lo rechaza como evidencia y acabas pagando dos veces, con el plazo ya encima.

El segundo es hacer un pentest sobre una casa sin ordenar. Si nadie ha mirado tus sistemas nunca, el informe serán cuarenta páginas de obviedades: parches pendientes, contraseñas por defecto, servicios olvidados. Has pagado tarifa de experto para que te confirmen lo evidente. Y una opinión que no me hace popular entre colegas: hay proveedores encantados de vendértelo igualmente, porque el informe sale gordo y el cliente queda impresionado. Un informe gordo no es un buen informe.

El tercero es la foto sin película: un pentest al año y once meses sin que nadie mire nada. Las vulnerabilidades graves que estamos viendo explotadas se aprovechan en días desde que se publican, no en meses. El pentest es una foto de un momento; la gestión continua es la película.

El cuarto: el alcance mal definido. Se contrata "auditar la web" y se dejan fuera la VPN, el correo y ese ERP accesible desde internet que montó un proveedor hace años. Lo que queda fuera del alcance es, con frecuencia, justo por donde se entra.

Y el quinto: el informe de doscientas páginas sin priorizar. Si el entregable no te dice qué arreglar primero, quién debería hacerlo y cuánto esfuerzo supone, has comprado papel, no seguridad.

Un caso que resume casi todos. Una empresa nos llegó con prisa: meses atrás había comprado una "auditoría de seguridad" barata para adjuntarla como evidencia a su certificación ISO 27001. El documento era, en realidad, la exportación de un escáner con la portada cambiada. Cuando el auditor lo revisó, lo rechazó: el requisito pedía un test de intrusión con evidencias de explotación, y aquello no lo era. Se encontró a tres semanas de la fecha de certificación sin la evidencia que creía tener y tuvo que encargar un pentest de verdad contra reloj, pagando dos veces por lo que, bien planteado desde el principio, habría sido un solo trabajo. No fue mala suerte: fue comprar por el título del PDF en lugar de por la frase exacta del requisito.

Qué necesitas tú, y en qué orden

Si nunca habéis hecho nada de esto, empieza por el análisis de vulnerabilidades sobre lo que tienes expuesto a internet, corrige lo grave y, a los dos o tres meses, haz el pentest para validar que el trabajo ha servido. En ese orden. Al revés, estás pagando por confirmar lo que ya se sabía.

Si te lo exige un tercero (auditor, cliente, aseguradora), vuelve a la frase exacta del requisito y compra exactamente eso. Ni más ni menos. Ya habrá tiempo de ampliar cuando la base esté cubierta.

Para una pyme, una cadencia razonable: revisión de vulnerabilidades continua, o al menos trimestral, sobre los sistemas expuestos, y un pentest anual o después de cambios importantes (una web nueva, una migración al cloud, un ERP recién implantado). Las dos piezas se retroalimentan: el pentest comprueba que tu gestión de vulnerabilidades y parches funciona de verdad, y la gestión continua evita que el pentest del año siguiente repita los mismos hallazgos. Si quieres ver cómo planteamos nosotros las pruebas de intrusión, con su metodología y sus alcances, ahí está nuestra área de seguridad ofensiva.

Preguntas frecuentes

¿Un análisis de vulnerabilidades me sirve como pentest para una auditoría?

No. Si el requisito dice test de intrusión o pentest, el escaneo no lo cubre y te lo van a rechazar. Al revés funciona solo a medias: un buen pentest incluye una fase de análisis, pero no sustituye el proceso continuo de gestión de vulnerabilidades que piden ISO 27001 o el ENS.

¿Un pentest puede tirarme los sistemas?

Bien planificado, no. Antes de empezar se acuerdan alcance, ventanas horarias y reglas de enfrentamiento: qué se puede explotar y qué solo se documenta. En entornos industriales, con máquinas de planta conectadas, la aproximación cambia por completo y merece capítulo aparte: ahí un escáner lanzado a lo loco sí puede parar producción.

¿Cada cuánto hay que hacer cada uno?

Como referencia para una pyme: análisis de vulnerabilidades continuo o trimestral sobre lo expuesto a internet, y pentest anual o tras cambios relevantes en la infraestructura o las aplicaciones.

¿Por qué un pentest cuesta bastante más que un análisis?

Porque pagas horas de una persona experta, no licencias de herramienta. Un análisis se apoya en automatización; un pentest son días de trabajo manual, de entender tu entorno y de pensar como un atacante. Si te ofrecen un pentest al precio de un escaneo, es un escaneo.

¿Te piden un pentest o un análisis y no sabes por dónde empezar?

Cuéntanos qué te han pedido y en qué punto está tu organización, y te decimos qué necesitas de verdad, sin venderte lo que no toca. Es el diagnóstico previo que hacemos en Meta-Data, sin compromiso.

Solicitar una propuesta

O escríbenos a [email protected].

Referencias verificadas a fecha de publicación. Las normas citadas (ISO/IEC 27001:2022, RD 311/2022 del ENS, Directiva NIS2 y su transposición en España) evolucionan. Revisa siempre la versión vigente antes de tomar decisiones de cumplimiento; este artículo orienta, no sustituye el análisis de tu caso concreto.