En resumen
La evaluación de vulnerabilidades busca de forma amplia las vulnerabilidades conocidas y las ordena por gravedad; el test de penetración intenta explotarlas para demostrar hasta dónde llega un atacante.
Los escáneres generan falsos positivos y no ven los errores de lógica de las aplicaciones: los resultados debe interpretarlos alguien que conozca redes y sistemas.
El NIST propone como modelo escaneos regulares intercalados con tests de penetración periódicos, con pruebas adicionales cuando cambian los sistemas.
La ISO 27001 (control 8.8) exige gestionar las vulnerabilidades técnicas; las especificaciones de la ACN exigen a las entidades NIS2 esenciales evaluaciones de vulnerabilidades y/o tests de penetración en los sistemas relevantes.
Una prueba vale por las correcciones que genera: prioridades, responsables, retest y aceptación documentada del riesgo residual.
Uno te dice qué puertas podrían estar abiertas, el otro intenta entrar de verdad. Así puedes elegir entre una evaluación de vulnerabilidades y un test de penetración, y decidir cada cuánto hacerlos.
Los dos términos se usan a menudo como sinónimos, tanto en los presupuestos de los proveedores como en los cuestionarios de los clientes. No lo son. La evaluación de vulnerabilidades busca de forma amplia las debilidades conocidas de tus sistemas; el test de penetración comprueba hasta dónde podría llegar un atacante aprovechándolas. Elegir el equivocado significa pagar por un resultado que no responde a tu pregunta: una lista de cientos de avisos cuando necesitabas saber si los datos de los clientes son accesibles, o un test a fondo de una aplicación cuando la red interna ni siquiera se ha inventariado.
En esta guía encontrarás las definiciones de las fuentes de referencia (NIST y OWASP), una tabla con las diferencias, tres situaciones tipo para entender qué test necesitas, las indicaciones sobre la frecuencia y la relación con la ISO/IEC 27001, la NIS2 y las especificaciones de la ACN italiana. Si quieres profundizar en el test de aplicaciones web, sus modalidades y el OWASP Top 10, lo tienes todo en nuestra guía del WAPT.
¿Qué es una evaluación de vulnerabilidades?
La evaluación de vulnerabilidades (vulnerability assessment) es una búsqueda sistemática de vulnerabilidades conocidas en sistemas, redes y aplicaciones. Responde a la pregunta: "¿dónde estoy expuesto y cuánto?".
La referencia más citada es la guía del NIST, el instituto estadounidense de normas y tecnología, dedicada a las pruebas de seguridad: la SP 800-115. En la sección sobre el escaneo de vulnerabilidades explica que los escáneres identifican hosts, sistemas operativos, aplicaciones y puertos abiertos, y los comparan con una base de datos de vulnerabilidades conocidas. Así encuentran versiones obsoletas y parches pendientes, además de configuraciones erróneas, y a menudo sugieren cómo corregirlos. El escaneo puede lanzarse desde la red o usar credenciales de acceso a los sistemas, que permiten ver mucho más a fondo.
Qué encuentra y qué no encuentra
Una evaluación de vulnerabilidades es amplia pero se queda en la superficie. Cubre muchos sistemas en poco tiempo, pero se detiene en la posible existencia de un fallo.
El propio NIST es explícito sobre los límites. Los escáneres tienen una tasa elevada de falsos positivos, es decir, señalan vulnerabilidades que no existen. Se basan en firmas y, por tanto, no reconocen lo que aún no está en su base de datos. Y no dicen cuál es el riesgo global de la red: evalúan un sistema cada vez. Las guías de OWASP añaden un límite específico para las aplicaciones web: las herramientas automáticas son genéricas, mientras que las aplicaciones casi siempre están hechas a medida, por lo que los errores de lógica se escapan. Un escáner no sabe que un usuario del portal de clientes no debería ver las facturas de otra empresa.
Escanear y evaluar no son lo mismo
Lanzar un escáner todavía no es hacer una evaluación de vulnerabilidades. La diferencia la marca la interpretación de los resultados por parte de alguien que conoce redes y sistemas, como recomienda la propia SP 800-115.
En la práctica, una buena evaluación elimina los falsos positivos, recalcula la gravedad según el contexto (una vulnerabilidad crítica en un servidor aislado pesa menos que una media en la tienda online) y entrega una lista ordenada por prioridad. El informe de un escáner con trescientas líneas en rojo, reenviado tal cual al proveedor informático, casi siempre acaba en un cajón. La misma lista, reducida a veinte acciones con un responsable y una fecha, se convierte en un plan de trabajo.
¿Qué es un test de penetración?
El test de penetración (pentest) es una prueba en la que especialistas simulan un ataque real, con autorización y reglas precisas, para saber si las defensas pueden eludirse y cómo.
La SP 800-115 lo define como una prueba de seguridad en la que los evaluadores imitan ataques reales para identificar formas de eludir las protecciones de una aplicación, un sistema o una red. Lo que marca la diferencia es la explotación: donde el escáner se limita a decir que una vulnerabilidad podría existir, el test de penetración confirma que existe intentando explotarla. A menudo combina varias debilidades menores para obtener un acceso que ninguna de ellas, por sí sola, permitiría. El resultado no es una lista, sino un relato: por dónde se entró, qué se alcanzó y con qué impacto.
Las cuatro fases según el NIST
El NIST describe el test de penetración en cuatro fases: planificación, descubrimiento, ataque e informe. En la planificación se fijan las reglas, los objetivos y la aprobación de la dirección.
La fase de descubrimiento recoge información e identifica los objetivos, a menudo precisamente con escáneres de puertos y de vulnerabilidades: por eso una evaluación de vulnerabilidades suele formar parte del test de penetración, no ser una alternativa. El ataque verifica las hipótesis y, cuando obtiene nuevos accesos, vuelve al descubrimiento para explorar lo que antes era invisible. El informe describe vulnerabilidades, riesgos y acciones de mitigación. Las fases del test de aplicaciones, con las modalidades black-box, grey-box y white-box, se describen en la guía del WAPT: aquí nos interesa la lógica general.
Alcance y reglas de compromiso
Un test de penetración conlleva riesgos reales y debe estar autorizado por escrito. El NIST recuerda que usa ataques reales sobre sistemas y datos de producción y que el riesgo de daños nunca puede eliminarse del todo.
Por eso la SP 800-115 incluye un modelo de reglas de compromiso. En la práctica, antes de empezar necesitas como mínimo: la lista exacta de direcciones, dominios y aplicaciones dentro del alcance, las franjas horarias acordadas, lo que queda excluido (por ejemplo, pruebas que pueden tumbar un servicio), un contacto interno localizable durante el test y un acuerdo sobre cómo tratar los datos personales que se encuentren. Si la aplicación está alojada en un proveedor cloud o la gestiona un proveedor, comprueba también que sus condiciones permitan el test e infórmale con tiempo.
Test de penetración y evaluación de vulnerabilidades: las diferencias en una tabla
La diferencia esencial está entre amplitud y profundidad. La evaluación de vulnerabilidades cubre mucho y profundiza poco; el test de penetración cubre menos y llega hasta el fondo.
Aspecto | Evaluación de vulnerabilidades | Test de penetración |
|---|---|---|
Pregunta a la que responde | ¿Dónde estoy expuesto? | ¿Hasta dónde llega un atacante? |
Método | Principalmente automático, con análisis de resultados | Principalmente manual, con herramientas de apoyo |
Explotación de fallos | No, se detiene en la posible existencia | Sí, de forma controlada |
Cobertura | Amplia: muchos sistemas y direcciones | Acotada: un alcance definido |
Falsos positivos | Frecuentes, hay que filtrarlos | Raros, porque cada fallo se verifica |
Errores de lógica de la aplicación | Difícilmente detectados | Forman parte del objetivo del test |
Impacto en los sistemas | Bajo, pero no nulo | Mayor, requiere reglas de compromiso |
Resultado | Lista de vulnerabilidades con gravedad y soluciones | Escenarios de ataque, impacto demostrado, prioridades |
Frecuencia típica | Regular y recurrente | Periódica y ligada a los cambios |
Ninguna de las dos columnas es "mejor". El NIST propone como modelo un programa que alterna escaneos regulares y pentests periódicos: los primeros mantienen bajo control la exposición diaria, los segundos comprueban que las defensas resisten de verdad.
¿Qué test necesitas? Tres situaciones tipo
La elección depende de la pregunta que debes responder, no del nombre del servicio. Estas son tres situaciones frecuentes en las pymes y la respuesta más sensata para cada una.
No sabes qué tienes expuesto: empieza por la evaluación de vulnerabilidades
Piensa en una empresa de distribución con 60 empleados, un ERP en sus instalaciones, acceso VPN para los comerciales, la web corporativa y una decena de servidores entre físicos y virtuales. Nadie ha hecho nunca un inventario completo. Aquí un test de penetración sería prematuro: primero tienes que saber qué hay.
Una evaluación de vulnerabilidades externa, sobre las direcciones públicas, y otra interna, con credenciales, sacan a la luz la VPN sin actualizar, la impresora de red con la contraseña de fábrica, el viejo servidor que nadie recordaba. El resultado alimenta el inventario de activos y el plan de parches, que también forman parte de las medidas mínimas de ciberseguridad por las que toda pyme debería empezar. El test de penetración llega después, cuando los fallos más evidentes están cerrados y merece la pena saber qué queda.
Tienes una aplicación con datos de clientes: necesitas un test de penetración
Ahora piensa en una empresa de software con un portal en el que los clientes suben documentos y consultan contratos. El riesgo principal aquí no es un parche pendiente, sino fallos en el control de acceso: un usuario que, cambiando un número en la dirección, abre el expediente de otro.
Este tipo de fallo es justo lo que un escáner no ve y lo que busca un test de penetración de aplicaciones, sobre todo en modalidad grey-box, con credenciales de distintos usuarios. Es el caso típico para un WAPT. Una evaluación de vulnerabilidades de la infraestructura que aloja el portal sigue siendo útil, pero no responde a la pregunta que importa a los clientes.
Un cliente o una licitación te pide "una prueba de seguridad"
El tercer caso es el más habitual: un cliente, en su cuestionario de seguridad de proveedores, pregunta si haces pruebas periódicas y te pide adjuntar una evidencia. Antes de contratar nada, aclara qué te están pidiendo.
Lee la pregunta al pie de la letra. "¿La empresa realiza escaneos periódicos de vulnerabilidades?" se cumple con un programa documentado de evaluación de vulnerabilidades. "¿La aplicación se ha sometido a un test de penetración realizado por terceros independientes?" exige un test de penetración real, con informe. En ambos casos no hace falta entregar el informe completo: una carta resumen con alcance, fecha, método y estado de las correcciones basta casi siempre. Cómo gestionar estas peticiones lo explicamos en la guía de cuestionarios de seguridad de clientes.
¿Cada cuánto hacer evaluaciones de vulnerabilidades y tests de penetración?
No existe una frecuencia válida para todos: la decide el riesgo, junto con las obligaciones a las que estás sujeto y los cambios en tus sistemas. Sí existen referencias sólidas.
La SP 800-115 observa que, por su coste e impacto potencial, un test de penetración de la red con periodicidad anual puede ser suficiente, siempre que se complemente con actividades menos costosas realizadas con regularidad, como los escaneos. Añade que una prueba es una foto de la seguridad en un momento concreto: si los sistemas cambian a menudo, conviene probar más a menudo. Las especificaciones básicas de la ACN para las entidades NIS2 esenciales, que veremos más adelante, exigen actividades periódicas y en todo caso antes de la puesta en producción de los sistemas relevantes.
En la práctica, un calendario razonable para una pyme tiene dos niveles. El primero es recurrente: evaluaciones de vulnerabilidades con una cadencia fija, más frecuente en los sistemas expuestos a internet, y un escaneo específico cada vez que el CSIRT Italia publica un aviso sobre un producto que usas. El segundo está ligado a los eventos: test de penetración antes de lanzar una nueva aplicación o un cambio importante, después de un incidente y con una periodicidad definida para las aplicaciones críticas. Elijas la frecuencia que elijas, escríbela en el procedimiento y respétala: para un auditor lo que cuenta es que la cadencia esté justificada y se mantenga.
¿Qué exigen la ISO 27001, la NIS2 y otras normas?
Ninguna de estas normas te obliga a elegir un test concreto por su nombre, con una excepción importante para las entidades NIS2 esenciales. Todas, sin embargo, exigen gestionar las vulnerabilidades y comprobar que las medidas funcionan.
ISO/IEC 27001: el control 8.8
En el Anexo A de la ISO/IEC 27001:2022, el control 8.8 trata la gestión de las vulnerabilidades técnicas: obtener información sobre las vulnerabilidades de los sistemas en uso, evaluar la exposición de la organización y adoptar las medidas adecuadas. Otros controles del mismo tema tecnológico tratan el desarrollo seguro y las pruebas de seguridad de las aplicaciones.
La norma no impone ni la evaluación de vulnerabilidades ni el test de penetración. Te deja la elección, siempre que sea coherente con el análisis de riesgos y con la Declaración de Aplicabilidad. En la auditoría se verifica el proceso: de dónde llega la información sobre vulnerabilidades, quién la evalúa, en qué plazos se corrige, cómo se gestiona lo que no puede corregirse enseguida. Un informe de evaluación de vulnerabilidades con su plan de corrección, o un test de penetración con su retest, son las evidencias más convincentes. El panorama completo de la norma está en nuestra guía de la ISO 27001.
NIS2 y las especificaciones básicas de la ACN
La Directiva NIS2, transpuesta en Italia por el Decreto Legislativo 138/2024, incluye entre las medidas mínimas la gestión y divulgación de vulnerabilidades y los procedimientos para evaluar la eficacia de las medidas de seguridad. Las especificaciones básicas adoptadas por la ACN, la Agencia italiana de Ciberseguridad Nacional, entran en detalle y distinguen entre entidades importantes y esenciales.
Para ambas exigen un plan de gestión de vulnerabilidades aprobado por los órganos de administración, la monitorización como mínimo de los canales del CSIRT Italia y la corrección rápida de las vulnerabilidades, o bien la aceptación documentada del riesgo. Para las entidades esenciales van más allá: en los sistemas relevantes exigen actividades de identificación de vulnerabilidades que incluyan como mínimo evaluación de vulnerabilidades y/o pentest, realizadas periódicamente y antes de la puesta en producción, documentadas con informes que describan actividades, resultados, vulnerabilidades e impacto. Es uno de los pocos textos que nombra expresamente las dos pruebas. Las especificaciones pueden actualizarse: comprueba siempre la versión vigente en la web de la ACN. Para saber si la NIS2 te afecta y cómo, lo tienes todo en la página dedicada a la NIS2.
RGPD y, para el sector financiero, DORA
El RGPD también entra en juego. El artículo 32 exige a quien trata datos personales un proceso de verificación regular de la eficacia de las medidas de seguridad. Un programa de pruebas documentado es una de las formas más directas de demostrarlo.
Para bancos, aseguradoras y otras entidades financieras, el Reglamento DORA prevé un programa de pruebas que incluye, entre otras, evaluaciones y escaneos de vulnerabilidades y tests de penetración, con pruebas al menos anuales de los sistemas que soportan funciones esenciales o importantes. Las entidades identificadas por las autoridades competentes deben realizar además, al menos cada tres años, pruebas de penetración avanzadas basadas en amenazas (TLPT). Si trabajas como proveedor TIC de estas entidades, espera que sus peticiones reflejen estos requisitos.
Del informe a las correcciones: cómo sacar partido a los resultados
Una prueba vale lo que las correcciones que genera. El NIST lo dice con claridad: los resultados deben tomarse en serio, las vulnerabilidades mitigarse y los resultados presentarse a la dirección.
El primer paso es la clasificación. Cada vulnerabilidad recibe una prioridad que tiene en cuenta la gravedad técnica y el contexto: cuán expuesto está el sistema, qué datos contiene, si ya existe un exploit conocido. Después se asigna cada acción a una persona con una fecha. Lo que no puedas corregir, por ejemplo el software de una máquina que el fabricante ya no actualiza, debe aislarse y el riesgo residual debe aceptarse de forma documentada, no olvidarse.
El segundo paso es la verificación. Tras las correcciones hace falta un retest, al menos sobre las vulnerabilidades más graves, para confirmar que el fallo está realmente cerrado y que la corrección no ha abierto otros. Sin retest, el informe describe el estado de un día pasado.
El tercer paso es conservar las evidencias. Informe, plan de corrección, resultado del retest y decisiones de aceptación del riesgo son documentos que sirven para la auditoría ISO, para la NIS2 y para los clientes. Guárdalos con fecha, versión y alcance, y mantén separado el informe técnico completo, que solo debe compartirse con quien tiene que corregir, del resumen para terceros.
Los errores más frecuentes
Algunos errores se repiten en casi todas las empresas que empiezan. Reconocerlos te ahorra una ronda de pruebas.
Llamar test de penetración a un escaneo automático: el informe no resiste la primera pregunta de un cliente experto o de un auditor.
Definir el alcance de forma vaga: el test cubre la web corporativa y deja fuera el área privada, donde están los datos.
Probar una vez y nunca más: un test de hace tres años no dice nada de los sistemas de hoy.
No hacer el retest: la corrección se queda en una intención, no en un hecho verificado.
Tratar el informe como un objetivo: la finalidad es reducir el riesgo, no archivar un documento.
Cómo te ayuda Complaion con evaluaciones de vulnerabilidades y tests de penetración
Complaion te ayuda a elegir la prueba adecuada y a convertirla en parte de tu sistema de gestión, no en un documento aislado.
Tu Lead Auditor dedicado parte del análisis de riesgos y de las obligaciones que te afectan (ISO 27001, NIS2, peticiones de clientes) y te propone el camino más adecuado: un programa de evaluación de vulnerabilidades, un test de penetración de las aplicaciones críticas o ambos, con una frecuencia justificada para escribir en el procedimiento. Cuando llega el informe, te ayuda a vincular hallazgos, plan de corrección y aceptación del riesgo residual al control 8.8 y a las medidas NIS2, para que en la auditoría presentes un proceso y no un anexo.
La plataforma recoge informes, planes de corrección y resultados de los retests como evidencias, gestiona los procedimientos con control de versiones y mantiene el calendario de pruebas periódicas, para que sepas cuándo toca la próxima evaluación y qué sigue abierto. Cuando se acerca la auditoría, encuentras las evidencias ya ordenadas. Para las aplicaciones web realizamos también el WAPT, el test de penetración de aplicaciones, y si estás construyendo tu sistema de gestión puedes hacerlo dentro del camino de certificación ISO 27001. Así trabajamos con más de 1.000 clientes. Para saber qué prueba necesitas de verdad, habla con un Lead Auditor.
Preguntas frecuentes sobre test de penetración y evaluación de vulnerabilidades
¿Cuál es la diferencia entre una evaluación de vulnerabilidades y un test de penetración?
La evaluación de vulnerabilidades busca de forma amplia y principalmente automática las vulnerabilidades conocidas de sistemas y aplicaciones, y las ordena por gravedad. El test de penetración simula un ataque real e intenta explotar las vulnerabilidades para saber hasta dónde llegaría un atacante. La primera mide la exposición, el segundo demuestra el impacto. A menudo el test de penetración incluye una fase de escaneo.
¿Una evaluación de vulnerabilidades puede sustituir a un test de penetración?
No, porque no explota las vulnerabilidades y detecta mal los errores de lógica de las aplicaciones, como un control de acceso defectuoso. También vale al revés: un test de penetración sobre un alcance limitado no sustituye a los escaneos regulares de todos los sistemas. Las fuentes de referencia, como la guía NIST SP 800-115, sugieren combinar los dos enfoques.
¿Cada cuánto hay que hacer un test de penetración?
Depende del riesgo, de las obligaciones y de cuánto cambian tus sistemas. La guía NIST SP 800-115 observa que un test anual de la red puede ser suficiente si se complementa con escaneos regulares. En todo caso conviene probar antes de poner en producción una aplicación nueva o modificada de forma relevante, y después de un incidente. Lo importante es que la frecuencia esté escrita y se respete.
¿El test de penetración es obligatorio para la ISO 27001?
No, la ISO/IEC 27001 no impone una prueba concreta. El control 8.8 exige gestionar las vulnerabilidades técnicas: recoger información, evaluar la exposición y actuar. El cómo lo eliges tú según el análisis de riesgos. Una evaluación de vulnerabilidades periódica o un test de penetración con retest son, sin embargo, evidencias muy eficaces en la auditoría.
¿La NIS2 obliga a hacer evaluaciones de vulnerabilidades o tests de penetración?
La NIS2 exige la gestión de vulnerabilidades y la verificación de la eficacia de las medidas. En Italia, las especificaciones básicas de la ACN exigen a todas las entidades un plan de gestión de vulnerabilidades. Para las entidades esenciales exigen además, en los sistemas relevantes, actividades que incluyan como mínimo evaluación de vulnerabilidades y/o pentest, periódicas y antes de la puesta en producción. Comprueba siempre la versión vigente de las especificaciones en la web de la ACN.
¿Un test de penetración puede bloquear los sistemas?
Sí, el riesgo existe y no puede eliminarse del todo, como recuerda el NIST. Se reduce con reglas de compromiso por escrito: alcance preciso, franjas horarias, exclusión de las pruebas más invasivas en sistemas críticos, un contacto interno localizable. En aplicaciones muy delicadas se puede probar un entorno de preproducción idéntico al de producción. También la evaluación de vulnerabilidades tiene un impacto bajo, pero no nulo en la red.
¿Puedo dar a los clientes el informe del test de penetración?
Mejor no, al menos no el completo: describe tus vulnerabilidades en detalle y es un documento útil para un atacante. A los clientes suele bastarles una carta resumen con alcance, fecha, método y estado de las correcciones. Si el cliente tiene una necesidad particular, valora un intercambio protegido por un acuerdo de confidencialidad o una revisión por videollamada.
