Informe de pentesting: qué debe incluir y cómo leerlo

Un informe de pentesting debe incluir seis bloques: resumen ejecutivo, alcance y metodología, hallazgos con evidencia, ruta de ataque, plan de corrección y anexos. Si al leerlo no sabes qué arreglar primero, el informe está mal escrito.

La diferencia con el volcado de un escáner está en la comprobación. Un escáner lista lo que sospecha y deja dentro los falsos positivos. Un informe de auditoría manual solo recoge lo que se verificó, y cuando el fallo se llegó a explotar trae los pasos para repetirlo. Veinte hallazgos comprobados ocupan menos y sirven más.

Qué debe incluir un informe de pentesting

El documento se lee de fuera hacia dentro: primero la decisión, después la prueba. Estos son los seis bloques y el orden en que aparecen.

• › Resumen ejecutivo: el estado general, los riesgos principales y las decisiones que hay que tomar. Sin una sola petición HTTP.
• › Alcance y metodología: qué se probó, qué quedó fuera, con qué credenciales y contra qué referencia. Es la parte que mira un auditor.
• › Hallazgos: uno por vulnerabilidad, con criticidad, evidencia y recomendación concreta.
• › Ruta de ataque: cómo se encadenaron los fallos, cuando se pudieron encadenar.
• › Plan de corrección: en qué orden y con qué esfuerzo estimado.
• › Anexos: peticiones, capturas y todo lo necesario para reproducir sin volver a preguntar.

El bloque de alcance es el que más se descuida y el primero que pide cualquiera que audite después. Un informe que no dice qué quedó fuera no demuestra nada sobre lo que quedó fuera.

Los cinco datos que lleva cada hallazgo

Cada hallazgo del informe lleva cinco datos, y con menos de cinco no se puede ni priorizar ni verificar la corrección.

• › Qué es y dónde está, con el activo concreto y no con una categoría genérica.
• › Qué pasa si se explota, dicho en consecuencias de negocio y no en jerga.
• › Su criticidad, con la puntuación CVSS y con el porqué de esa puntuación.
• › La evidencia: captura, petición o registro que demuestre que existe.
• › Los pasos para reproducirlo, si hubo explotación.

El quinto es el que más se echa de menos cuando falta. Sin pasos para reproducir, tu equipo no puede confirmar que arregló lo que había, y la discusión sobre si el hallazgo era real se eterniza durante semanas. En Pentesting Team ese apartado va en todos los hallazgos que se llegaron a explotar, y existe por un motivo poco comercial: para que la comprobación no dependa de nosotros. Nadie audita bien lo que ha configurado, así que el proveedor que te administra los sistemas puede rehacer la prueba y cerrarla sin llamar a nadie.

Cómo se lee la severidad sin que la escala decida por ti

CVSS es la escala estándar que puntúa una vulnerabilidad de 0 a 10 según sus características técnicas. La versión vigente es CVSS v4.0, publicada por FIRST en noviembre de 2023, y su tabla 22 reparte las puntuaciones así.

Las dos primeras columnas son de FIRST. La tercera es nuestra, y ahí está el matiz que casi nadie cuenta: la propia especificación dice que usar esas etiquetas cualitativas es opcional y que no hay ningún requisito de incluirlas al publicar una puntuación. Es decir, la palabra «crítica» no viene del estándar como una obligación. Viene de una convención que después cada empresa aplica como quiere.

Por eso la severidad se lee siempre pegada al activo. La misma vulnerabilidad en un entorno de pruebas aislado y en el servidor de facturación no merece el mismo sitio en la cola. Un 9,8 que no toca datos de nadie corre menos prisa que un 6,5 en el sistema que factura, y esa lectura la pone el contexto.

¿En qué orden se corrige?

Por lo explotable y por lo que expone datos, no por la puntuación más alta de la lista. La agencia estadounidense CISA mantiene el catálogo de vulnerabilidades explotadas conocidas, que a septiembre de 2026 recoge 1.699 CVE de las que hay constancia de explotación real, y recomienda usarlo como entrada del marco de priorización. Si un hallazgo de tu informe está en esa lista, deja de ser una hipótesis.

El orden que funciona tiene tres tramos. Primero lo que un atacante usaría para entrar desde fuera. Después lo que le permite moverse una vez dentro. Y al final lo que solo tiene valor si ya ha conseguido las dos cosas anteriores.

Y los hallazgos que decides no arreglar, ¿qué?

Se aceptan por escrito, con fecha y con quién lo decide. No todo lo que sale en un informe merece el coste de arreglarlo, y decirlo forma parte del trabajo: una baja en un componente que se retira en tres meses no justifica tocar producción.

Lo que no vale es dejar el hallazgo sin respuesta. Un informe con veinte hallazgos y once decisiones registradas está cerrado; uno con veinte hallazgos y silencio en nueve vuelve entero en la siguiente auditoría, y para entonces nadie recuerda si aquello se descartó a propósito o se pasó por alto.

La ruta de ataque es lo que separa un informe de un listado

Un listado de vulnerabilidades sueltas se lee como una queja. La secuencia que va del formulario público hasta el servidor de nóminas se lee como un riesgo, y es lo que la dirección recuerda al día siguiente. Encadenar dos fallos que por separado no son nada es justo lo que un escáner no hace, y es la parte del trabajo que sostiene el precio de una auditoría de infraestructura interna, donde la pregunta que se responde no es qué vulnerabilidades hay sino hasta dónde se llega en el dominio.

El resumen ejecutivo es otro documento, para otra persona

La dirección no necesita la petición HTTP que demostró el fallo. Necesita saber qué riesgo hay, qué costaría que se materializara y qué decisiones tocan este trimestre. Por eso los resultados se presentan en directo, en media hora, y el PowerPoint que usamos se entrega para que quien no estuvo en la reunión pueda leerlo después, igual en un pentesting de aplicaciones web que en una revisión de la red interna.

Qué no debería aparecer en un informe

• › Relleno de teoría copiado de la descripción genérica de la vulnerabilidad.
• › Capturas de una herramienta sin explicar qué demuestran.
• › Severidades sin justificar, o todas altas.
• › Recomendaciones del tipo «revisar la configuración», que no dicen qué revisar.

El último es el más caro. Una recomendación que no se puede convertir en un ticket no se ejecuta, y el hallazgo sigue abierto seis meses después con el informe archivado.

Cuánto tarda el informe y qué pasa después

El informe técnico llega entre uno y tres días después de terminar el trabajo de campo. Estas son las seis fases de una auditoría de Pentesting Team, con lo que dura cada una y lo que se entrega al acabarla.

Los precios de partida están publicados por tipo de auditoría: una de superficie externa parte de 450 €, una de aplicación web de 1.140 € y una de infraestructura interna de 1.520 €. El precio final depende del número de activos y de roles de usuario, y el desglose de qué entra en cada caso está en el artículo sobre el precio de una auditoría de ciberseguridad.

El retest se puede pedir hasta seis meses después de la entrega. Ese plazo no es un capricho: es lo que suele tardar una organización mediana en cerrar los hallazgos altos sin parar el resto del trabajo. A partir de ahí, la siguiente prueba ya no es un retest sino una auditoría nueva, y cuándo toca repetirla depende de cuánto haya cambiado el sistema, no del calendario.

Qué pedir antes de firmar

Pide un informe de ejemplo, aunque venga anonimizado, y ábrelo por un hallazgo cualquiera. En dos minutos se ve si hay evidencia y pasos o si son párrafos genéricos con capturas de una herramienta. Pregunta también contra qué metodología se trabaja: para web y API la referencia es la OWASP Web Security Testing Guide, cuya versión estable sigue siendo la 4.2, publicada en diciembre de 2020. Y pregunta si el retest entra en el precio y en qué plazo, porque una auditoría sin verificación posterior deja el trabajo a la mitad.

Si además la auditoría tiene que servirle a un certificador, mira antes qué evidencia espera el auditor de la ISO 27001: el informe que vale para tu equipo técnico y el que vale para una certificación no siempre traen los mismos apartados.

Si ya tienes un informe encima de la mesa, ábrelo hoy por un hallazgo del que te acuerdes y busca los pasos para reproducirlo. Si no están, ya sabes qué exigir en el pliego de la próxima. Y si vas a encargar el primero, pide el informe de ejemplo antes que el presupuesto: el precio se compara en un minuto y la calidad del informe no.