Cómo interpretar un informe de pentesting

Introducción: por qué importa entender un informe de pentesting

Un informe de pentesting resume los resultados de una prueba de penetración realizada sobre los sistemas de una organización. Sin embargo, recibirlo no es lo mismo que entenderlo. Muchas empresas se limitan a buscar un «aprobado» o «suspenso» al final del documento y archivarlo, cuando la verdadera utilidad reside en lo que se hace con la información que contiene.

Un informe profesional debe ser útil tanto a perfiles técnicos como directivos. La dirección necesita una visión estratégica de los riesgos para tomar decisiones de presupuesto y prioridad. El equipo técnico necesita detalle suficiente para corregir cada fallo. Cuando ambos grupos interpretan bien el documento, la empresa pasa de «cumplir el expediente» a reducir riesgos reales.

Un informe de pruebas de penetración típico incluye resumen ejecutivo, contexto, alcance, metodología, vulnerabilidades con evidencias, plan de remediación y resultados del retest. Antes de contratar un servicio de pentesting, conviene saber cómo se va a leer y aprovechar el informe resultante.

Interpretar correctamente cada sesión de pruebas aporta beneficios concretos:

• Decisiones informadas: la dirección entiende dónde invertir en seguridad.
• Remediación eficaz: los equipos técnicos saben exactamente qué corregir y en qué orden.
• Cumplimiento demostrable: auditores y reguladores reciben la documentación que necesitan.
• Mejora continua: cada informe alimenta indicadores que miden la evolución de la postura de seguridad.

Qué es un informe de pentesting y qué preguntas responde

Un informe de pentesting es el documento formal que recoge los descubrimientos de una campaña de pruebas de penetración ejecutada en una fecha, un entorno y con unos objetivos concretos. Por ejemplo, un pentest realizado en junio de 2026 sobre el sitio web de un e-commerce evaluará las aplicaciones expuestas a internet, la configuración de servidores y la protección de datos de clientes.

Este tipo de informe identifica vulnerabilidades en sistemas y aplicaciones, y en una sola campaña se pueden encontrar hasta 21 tipos diferentes de vulnerabilidades. Su valor va mucho más allá de un listado técnico: traduce hallazgos en riesgos para el negocio.

Distinguir entre análisis de vulnerabilidades periódicos y auditorías puntuales (tras un cambio de infraestructura o antes de un lanzamiento) y pruebas recurrentes (trimestrales o mensuales) cambia la forma de interpretar tendencias. Un informe recurrente permite detectar si ciertos fallos se repiten o si determinados sistemas siempre aparecen como los más expuestos.

Tras leer el informe, cualquier persona debería poder responder, como mínimo, estas preguntas:

• ¿Qué activos, redes, APIs o aplicaciones se probaron exactamente?
• ¿Qué metodología, herramientas y estándares se utilizaron?
• ¿Cuántas vulnerabilidades críticas, altas, medias y bajas se encontraron?
• ¿Qué sistemas están más expuestos y qué datos podrían verse comprometidos?
• ¿Qué plazo razonable de remediación necesita cada hallazgo?
• ¿Qué medidas concretas se recomiendan y quién debe ejecutarlas?

Estructura típica de un informe de pruebas de penetración

Un informe profesional de pruebas de penetración sigue una estructura que facilita la lectura a distintos públicos. Muchos proveedores separan el contenido en dos bloques -informe ejecutivo e informe técnico- para que cada lector encuentre lo que necesita sin perderse en secciones que no le corresponden. Los informes deben incluir vulnerabilidades y recomendaciones para mitigar cada una de ellas, y el plazo estándar para entregar el documento es de 7 a 14 días hábiles tras finalizar las pruebas.

Estas son las secciones habituales y lo que el lector debe esperar en cada una:

• Portada: incluye información sobre la empresa auditada, nombre del proyecto, fechas de la sesión de pruebas, responsables del proveedor y del cliente, y nivel de confidencialidad. Es la identificación inequívoca del alcance temporal y contractual.
• Control de versiones: historial de cambios del documento, útil cuando hay revisiones tras remediación parcial.
• Índice: facilita la navegación por las secciones del informe y permite saltar directamente al listado de vulnerabilidades, la descripción del entorno o el plan de remediación.
• Resumen ejecutivo: un informe de pentesting debe incluir un resumen ejecutivo que sintetice riesgos y conclusiones para la dirección.
• Alcance: define qué sistemas fueron auditados y cuáles estaban fuera de alcance.
• Metodología: fases, estándares, herramientas y limitaciones.
• Resultados técnicos: listado detallado de vulnerabilidades con evidencias, impacto y severidad.
• Valoración de riesgo: traducción del impacto técnico al contexto de negocio.
• Recomendaciones y plan de remediación: acciones concretas, prioridades y responsables.
• Anexos: capturas de pantalla, logs, payloads, referencias a estándares como PTES y documentación complementaria.

Cada sección tiene un papel distinto; entenderlo evita perder tiempo buscando detalle técnico en páginas pensadas para directivos.

Cómo leer el resumen ejecutivo sin ser técnico

El resumen ejecutivo está diseñado para dirección general, responsables de negocio y compliance. Debe poder leerse en menos de 10 minutos y ocupar, como máximo, una o dos páginas del documento total. Su misión es clara: el resumen ejecutivo explica el nivel de riesgo en un lenguaje no técnico, sin payloads, sin comandos, sin jerga innecesaria.

Un buen resumen ejecutivo incluye, como mínimo, estos elementos:

• Visión global del nivel de riesgo (crítico, alto, moderado, bajo) con la explicación de por qué se ha asignado ese nivel.
• Número de vulnerabilidades agrupadas por criticidad.
• Activos más expuestos, especialmente los que manejan datos sensibles o pagos.
• Impacto potencial en negocio: interrupciones de servicios, exposición de datos de usuarios, multas regulatorias, daño reputacional.
• Síntesis de las recomendaciones clave con urgencia clara.

Un ejemplo de redacción eficaz sería: «La exposición global al riesgo se considera ALTA debido a cuatro vulnerabilidades críticas asociadas al módulo de pagos en línea, que permitirían a un atacante acceder a datos financieros de clientes.» Este tipo de frase transmite valor sin necesidad de conocimiento técnico.

Al revisar el resumen, la dirección debería fijarse en matrices de riesgo, gráficos de barras y mapas de calor, no en capturas de Burp Suite. Un informe de pentesting bien elaborado mejora la confianza de clientes y socios al demostrar que la organización gestiona activamente su seguridad.

La pregunta clave que debe responder esta sección es: ¿qué decisiones de negocio debo tomar ahora? Presupuesto adicional, cambio de prioridades, sustitución de un proveedor, comunicación a socios… todo eso debe desprenderse del resumen ejecutivo.

Contexto, alcance y tipo de auditoría: qué se probó exactamente

Antes de interpretar cualquier hallazgo, hay que entender el alcance: qué sistemas, aplicaciones, redes o APIs se incluyeron en las pruebas y cuáles quedaron fuera. El alcance define qué sistemas fueron auditados y cuáles estaban fuera de alcance, y esa delimitación condiciona todas las conclusiones del informe.

Ejemplos típicos de alcance incluyen:

• Pentest de aplicaciones web externas en el dominio corporativo (por ejemplo, portal de clientes y pasarela de pago).
• Pruebas internas sobre la red de oficinas en Madrid y Barcelona.
• Auditoría de API REST del sistema de facturación.
• Evaluación de configuración de entornos cloud (AWS, Azure).

El pentesting como estrategia para probar la seguridad ayuda a evaluar la eficacia de las medidas de seguridad vigentes, pero solo sobre lo que se ha probado. Extrapolar resultados a sistemas que no formaron parte del alcance es un error frecuente.

Las diferencias entre tipos de auditoría también condicionan la interpretación:

• Caja negra: el pentester no tiene acceso ni conocimiento previo, simulando un atacante externo. Detecta amenazas visibles pero puede pasar por alto fallos de lógica interna.
• Caja blanca: acceso completo al código y la arquitectura. Mayor profundidad, pero más costoso en tiempo y recursos.
• Caja gris: el probador cuenta con cierto conocimiento (credenciales limitadas, documentación parcial). Equilibra cobertura y realismo.

Las fechas de la sesión de pentesting son igualmente importantes: si hubo ventanas de mantenimiento, cambios de versión o despliegues durante las pruebas, los resultados pueden no reflejar el estado habitual del entorno. El lector debe validar que el alcance descrito coincide con lo contratado y que el informe no incluye sistemas ajenos al mandato, algo relevante para temas legales y de responsabilidad.

Metodología y estándares: cómo se hicieron las pruebas

La sección de metodología explica el «cómo» de la auditoría. Los informes deben alinearse con normas como ISO 27001 y NIST, y los marcos de referencia más citados en informes profesionales son:

• OWASP Testing Guide y OWASP Top 10: referencia para pruebas de aplicaciones web.
• NIST SP 800-115: guía técnica para pruebas de seguridad de la información.
• OSSTMM: metodología abierta para pruebas de seguridad.
• ISO/IEC 27001/27002: marco de gestión de seguridad de la información.

Las auditorías de seguridad deben seguir normativas como ISO 27001 y NIST para garantizar rigor y reproducibilidad. Las regulaciones requieren prácticas de seguridad rigurosas, y una metodología documentada es la evidencia de que se han seguido.

La metodología suele detallar fases consecutivas: reconocimiento, análisis de servicios, identificación de vulnerabilidades, explotación, escalada de privilegios y post-explotación. Cada paso revela información distinta sobre la postura de seguridad.

Al revisar esta sección, el lector debe comprobar:

• Que se referencian estándares reconocidos y no solo herramientas propietarias.
• Que se han combinado herramientas automáticas (escáneres, fuzzers) con pruebas manuales, ya que menos del 10 % de los profesionales confían únicamente en herramientas automatizadas para encontrar vulnerabilidades.
• Que se describen las limitaciones: exclusión de ataques DoS por impacto en producción, ventanas horarias restringidas, sistemas excluidos por el cliente.
• Que las fases están fechadas, lo que permite reproducibilidad y defensa ante auditorías externas.

Metodologías alineadas con estándares facilitan integrar el informe de pentesting en programas de cumplimiento como PCI DSS, ENS o HIPAA, donde demostrar el proceso es tan importante como demostrar los resultados.

Cómo interpretar la clasificación de vulnerabilidades y el riesgo

La mayoría de informes utilizan CVSS v3.1 para puntuar vulnerabilidades y agruparlas en categorías: Crítica (9.0–10.0), Alta (7.0–8.9), Media (4.0–6.9), Baja (0.1–3.9) e Informativa. Las vulnerabilidades se clasifican según la puntuación CVSS y se priorizan según su severidad usando ese mismo sistema. Un informe técnico detalla vulnerabilidades y su severidad según CVSS, permitiendo comparaciones objetivas.

En términos prácticos para el negocio:

• Crítica: permite tomar control total de un sistema o acceder a datos sensibles sin restricciones. Requiere acción inmediata.
• Alta: compromete la confidencialidad o integridad de forma significativa, aunque puede requerir condiciones específicas.
• Media: representa un riesgo real pero con menor probabilidad o impacto limitado.
• Baja/Informativa: hallazgos que conviene corregir pero no suponen amenaza inmediata.

El pentesting ayuda a visualizar el impacto real que tendría un ataque en los negocios, pero el lector debe ir más allá de la puntuación numérica. Una vulnerabilidad con CVSS alto que requiere acceso físico al servidor puede tener menor urgencia real que otra con puntuación algo inferior pero explotable remotamente desde internet.

Ejemplos frecuentes en tablas de vulnerabilidades incluyen SQL Injection, XSS almacenado, ausencia de tokens anti-CSRF y cifrados débiles en TLS. Cada entrada debe mostrar descripción, evidencia, pasos para reproducir y recomendaciones.

Se recomienda crear, a partir del informe, una matriz de riesgos interna que cruce estos cuatro ejes:

• Criticidad técnica (CVSS).
• Facilidad de explotación (¿se necesita acceso interno o basta con una entrada desde internet?).
• Visibilidad pública (¿afecta al sitio web principal o a un sistema interno?).
• Coste estimado de remediación.

Lectura detallada de los hallazgos técnicos: qué buscar en cada vulnerabilidad

El corazón del informe es el listado de hallazgos técnicos. Cada vulnerabilidad suele presentarse como una ficha con campos estándar que permiten evaluarla de forma independiente. El formato habitual incluye:

• Nombre y referencia: identificador único, CWE o CVE cuando aplique.
• Descripción: explicación clara del fallo, comprensible sin necesidad de herramienta específica.
• Impacto: qué podría conseguir un atacante explotando esta vulnerabilidad (acceso a datos, control del sistema, movimiento lateral).
• Evidencia: capturas de pantalla, respuestas HTTP, logs, outputs de herramientas como nmap o Burp Suite.
• Pasos de explotación: secuencia reproducible con URLs exactas, parámetros y payloads utilizados.
• Severidad: puntuación CVSS con su vector completo.
• Recomendaciones: acciones concretas para corregir el fallo.

El lector técnico debe verificar que cada vulnerabilidad incluye información suficiente para reproducirla de forma controlada en un entorno de pruebas. Si una ficha solo dice «se detectó XSS en la aplicación» sin indicar la URL, el parámetro vulnerable ni el payload usado, la calidad del informe es insuficiente.

Checklist para revisar cada hallazgo:

• ¿La descripción permite entender el problema sin consultar fuentes externas?
• ¿La evidencia visual confirma que no es un falso positivo de un escáner automático?
• ¿Hay coherencia entre el impacto descrito y la severidad asignada? Tanto el alarmismo como la infravaloración restan credibilidad.
• ¿Las recomendaciones son accionables? Deben incluir, por ejemplo, qué configuración cambiar, qué parche aplicar o qué control implementar.
• ¿Se incluyen referencias a estándares (OWASP, CWE) para que el equipo de desarrollo pueda investigar en profundidad?

Una plantilla de ficha bien construida ahorra horas de trabajo al equipo de remediación y reduce malentendidos entre seguridad y desarrollo.

De informe a plan de acción: priorizar la remediación

Un informe sin plan de acción es contenido que se archiva y se olvida. La remediación debe incluir un plan de acción detallado para abordar vulnerabilidades, transformando los hallazgos en tareas concretas con responsables, plazos y recursos asignados.

Los criterios de priorización combinan varios factores:

• Criticidad CVSS: las vulnerabilidades críticas y altas van primero.
• Exposición al exterior: un fallo en el sitio web público tiene más urgencia que uno en una herramienta interna.
• Datos implicados: si afecta a datos personales o financieros, la obligación regulatoria acelera los plazos.
• Requisitos normativos: PCI DSS para sistemas de pago, RGPD para datos de usuarios europeos.
• Complejidad de corrección y dependencia de terceros: algunas correcciones requieren coordinación con proveedores o ventanas de mantenimiento.

El pentesting ayuda a priorizar inversiones en seguridad según las amenazas más críticas, y realizar pentesting puede prevenir costos asociados a ataques cibernéticos cuando la remediación es oportuna. Según datos del State of Pentesting Report 2025 de Cobalt, la mediana de tiempo para resolver vulnerabilidades serias ha caído de 112 días en 2017 a 37 días recientemente, pero solo alrededor del 60 % de los hallazgos serios se resuelven en organizaciones grandes.

Se recomienda crear una tabla tipo backlog a partir del informe:

Cómo aprovechar la sesión de presentación del informe con los pentesters

Tras la entrada del informe, es habitual realizar una o varias sesiones de presentación donde el equipo de pentesters responde dudas y amplía el detalle de cada hallazgo. Esta reunión es una oportunidad que muchas organizaciones desaprovechan.

Para sacarle el máximo valor, conviene preparar la sesión con anticipación:

• Leer el informe completo antes de la reunión.
• Recopilar preguntas por área: infraestructura, aplicaciones, cloud, cumplimiento.
• Priorizar los temas críticos para no perder tiempo en hallazgos informativos.

Ejemplos de preguntas inteligentes para la sesión:

• ¿Por qué esta vulnerabilidad se marcó como crítica si el sistema afectado es interno?
• ¿Qué alternativas de mitigación existen si la solución ideal requiere un cambio de arquitectura costoso?
• ¿Cómo evitar regresiones de este tipo de fallo en futuras versiones?
• ¿Qué paso adicional habría permitido escalar desde esta vulnerabilidad media a un compromiso mayor?

Durante la presentación, la dirección debería centrarse en las implicaciones de negocio y el equipo técnico en aspectos de explotación, arquitectura y cambios concretos en código o configuración. Es conveniente grabar la sesión (si la política de privacidad interna lo permite) y generar actas con acuerdos, decisiones y próximos pasos vinculados al informe.

Esas actas se convierten en documentos de seguimiento que complementan el informe y facilitan el control de avance en la remediación.

Uso del informe de pentesting para cumplimiento normativo y auditorías

Un informe de pentesting ayuda a demostrar cumplimiento normativo ante auditores y reguladores. El cumplimiento normativo facilita auditorías y se ajusta a normativas como ISO 27001 y PCI DSS, mientras que el pentesting contribuye al cumplimiento de normativas de seguridad de forma tangible y verificable.

Las normativas relevantes incluyen RGPD, NIS2 y ENS, entre otras. El cumplimiento normativo evita multas y sanciones legales que pueden ser significativas, especialmente bajo marcos como RGPD o PCI DSS.

Las partes del informe que suelen solicitar los auditores son:

• Resumen ejecutivo con la valoración global de riesgo.
• Alcance y metodología para verificar que se cubrieron los sistemas relevantes.
• Listado de vulnerabilidades con severidad y estado de remediación.
• Evidencias seleccionadas que demuestren la profundidad de las pruebas.
• Plan de acción con fechas, responsables y seguimiento.

Vincular hallazgos del informe con controles concretos añade valor. Por ejemplo, correlacionar una vulnerabilidad de gestión de sesiones con controles específicos del Anexo A de ISO 27001, o mapear fallos de cifrado a requisitos de PCI DSS sección 11.

Mantener un historial organizado de informes de pentesting, planes de acción y resultados de retest demuestra evolución y mejora continua. La frecuencia y el alcance de las pruebas de penetración pueden venir impuestos por contratos con clientes, cláusulas de ciberseguro o requisitos regulatorios sectoriales en finanzas, salud o administración pública.

Esa documentación histórica no es solo una buena práctica: es un activo que protege a la organización ante inspecciones, reclamaciones de socios comerciales y procesos legales.

Errores habituales al interpretar un informe de pentesting (y cómo evitarlos)

Una comprensión deficiente del informe puede hacer que la empresa repita año tras año los mismos hallazgos sin avanzar en su postura de seguridad. Estos son los errores más frecuentes y sus alternativas:

• Centrarse solo en el número total de vulnerabilidades. Un informe con 50 hallazgos bajos puede ser menos preocupante que uno con 3 críticos. La prioridad la marca la severidad y el impacto de negocio, no la cantidad.
• Ignorar las vulnerabilidades bajas. Varias vulnerabilidades de baja severidad pueden encadenarse para lograr un compromiso mayor. No descartarlas sin análisis previo.
• Confundir impacto técnico con impacto de negocio. Un CVSS alto en un sistema aislado sin datos sensibles puede tener menor urgencia real que un CVSS medio en el portal de clientes. El contexto lo cambia todo.
• Tratar el informe como un fin, no como un punto de partida. El concepto clave es que el documento inicia un proceso de remediación y seguimiento, no lo cierra.
• Delegar toda la interpretación en el proveedor. Si los equipos internos de desarrollo y operaciones no participan en la lectura, las recomendaciones no se ajustarán a la realidad operativa y quedarán sin implementar.
• No actualizar el informe tras la remediación. No documentar decisiones como la aceptación de ciertos riesgos ni vincular el informe a métricas de seguridad convierte el documento en algo estático e inútil.

Buenas practicas para evitar estos errores:

• Realizar revisiones conjuntas periódicas entre seguridad, desarrollo y operaciones.
• Usar herramientas de ticketing para trackear cada acción derivada del informe.
• Actualizar la matriz de riesgos tras cada ciclo de remediación.
• Documentar lecciones aprendidas para que el siguiente pentest no repita los mismos descubrimientos.

Más allá del informe: retest, seguimiento y mejora continua

El ciclo no termina con la entrega del informe. El siguiente paso clave es el retest o revalidación de vulnerabilidades tras aplicar correcciones. La remediación incluye validar correcciones implementadas tras un pentesting, confirmando que cada fallo ha sido efectivamente cerrado y no solo parcheado en superficie.

Un buen informe suele incluir una sección o anexo dedicada al resultado del retest: vulnerabilidades cerradas, parcialmente mitigadas o aún explotables, con nuevas evidencias. Un informe de confirmación certifica la eliminación de vulnerabilidades críticas y proporciona tranquilidad verificable al negocio.

El proceso de remediación debe documentarse para auditorías futuras. Cada vez que se cierra una vulnerabilidad, el registro debe incluir qué se hizo, quién lo hizo, cuándo y cómo se verificó.

A lo largo del tiempo, los resultados de múltiples informes permiten construir indicadores de valor estratégico:

• Tiempo medio de remediación (MTTR): ¿está mejorando o empeorando?
• Vulnerabilidades críticas abiertas: ¿cuántas persisten tras cada ciclo?
• Hallazgos repetidos: ¿se están corrigiendo las causas raíz o solo los síntomas?
• Tendencia general: ¿la organización madura en su postura de seguridad o se estanca?

Integrar las conclusiones del informe en el programa de seguridad implica actualizar políticas, revisar configuraciones estándar, formar al personal y aplicar cambios en el ciclo de desarrollo seguro (SDLC). Las lecciones aprendidas de cada informe deben compartirse en sesiones internas para que desarrollo, operaciones y negocio entiendan qué falló y cómo evitarlo.

Interpretar bien los informes a lo largo de varios ejercicios permite medir la madurez de la seguridad, no solo el resultado de una campaña puntual de pruebas.

Conclusiones: convertir el informe en decisiones de negocio

Un informe de pentesting es una herramienta de negocio, no solo un documento técnico. Su valor real aparece cuando se interpreta de forma sistemática y se traduce en acciones concretas: presupuestos ajustados, plazos definidos, responsables asignados y métricas de seguimiento activas. Sin esa traducción, el informe es papel archivado.

Dirección, seguridad, desarrollo y operaciones deben compartir una lectura coordinada del documento, especialmente del resumen ejecutivo, la matriz de riesgos y el plan de remediación. Cada persona involucrada aporta una perspectiva distinta que enriquece la interpretación y garantiza que las características de cada hallazgo se evalúen en su contexto real.

Revisa tus últimos informes de pruebas de penetración usando las pautas descritas en este artículo. Detecta si hay huecos en la interpretación, en el seguimiento o en la forma de documentar las cosas que se corrigieron. Y a la hora de elegir proveedor, no evalúes solo la calidad técnica de las pruebas: evalúa también la claridad del informe entregado y la calidad del acompañamiento posterior. Un buen informe de pentesting ayuda a evaluar la eficacia de las medidas de seguridad y convierte cada campaña en un paso más hacia una organización realmente resiliente.