Informe de pentest: qué debe incluir

El problema: un informe que parece pentest y no lo es

Imagina la escena: el auditor pide la evidencia del test de intrusión anual, el equipo entrega un PDF de 60 páginas y la primera pregunta es "¿dónde está la prueba de que esto se explotó?". Nadie sabe responder. El pentest costó dinero y semanas, y el requisito sigue abierto. Pasa más a menudo de lo que debería, y casi siempre la causa está en el informe, no en la prueba.

El informe es lo único que queda después de un pentest. El equipo de seguridad lo usa para corregir, el auditor para validar un requisito y el cliente enterprise para decidir si firma. Una prueba excelente con un informe débil vale poco; un informe bonito generado a partir de un escaneo automático vale menos aún.

Esta guía describe las secciones que necesita un informe de pentest serio, cómo reconocer el "volcado de escáner" y una checklist para usar al recibir (o comprar) el entregable. Si aún estás eligiendo proveedor, empieza por las 10 preguntas antes de contratar un pentest.

Quién lee cada parte del informe

Un informe serio atiende a varios lectores a la vez. Saber quién lee qué ayuda a juzgar si la estructura es correcta:

Sección	Quién la lee	Pregunta que responde
Resumen ejecutivo	Dirección, CISO, legal	¿Cuál es el riesgo real y qué decidimos primero?
Alcance y metodología	Auditor, cumplimiento	¿La prueba cubrió lo que exige la norma?
Clasificación de riesgo	CISO, gestión de riesgos	¿Qué corregimos antes?
Hallazgos con evidencia	Desarrolladores, infraestructura	¿Cómo lo reproduzco y lo corrijo?
Mapeo normativo	Auditor, cumplimiento	¿Qué requisito cubre esta prueba?
Reensayo	Auditor, CISO	¿Funcionó la corrección?
Carta de atestación	Clientes enterprise, socios	¿Puedo confiar en este proveedor?

1. Resumen ejecutivo: para quien decide

La primera página debe poder leerla alguien no técnico y responder cuatro cosas: qué se probó, cuál es el resultado general, qué riesgos exigen una decisión y qué hacer primero. Busca:

Un veredicto claro (por ejemplo, "fue posible acceder a datos de otros clientes sin autenticación válida"), no solo un número de vulnerabilidades.
Los tres a cinco hallazgos que de verdad importan al negocio, en lenguaje sencillo.
Contexto: qué no se probó y por qué, para que nadie lea "sin hallazgos críticos" como "sin riesgo".

Un resumen que dice "se encontraron 143 vulnerabilidades" sin priorizar es una señal de alerta.

2. Alcance, reglas de compromiso y metodología

Esta sección es la que hace defendible el informe ante un auditor. Debe incluir:

Objetivos probados: dominios, IPs, aplicaciones, APIs, entornos (producción o preproducción) y versión probada.
Ventana de prueba y enfoque: caja negra, gris o blanca, con o sin credenciales, y qué quedó fuera de alcance. Consulta las diferencias en Qué es un pentest y sus tipos.
Metodología documentada: referencias como OWASP WSTG, OWASP API Security Top 10, PTES o NIST SP 800-115. El informe debe decir qué se aplicó, no solo listar resultados.
Limitaciones: bloqueos por WAF, restricciones de carga, cuentas de prueba no disponibles.

Sin alcance y metodología, el auditor no puede confirmar que la prueba cubrió lo que exige la norma.

3. Clasificación de riesgo: CVSS más impacto en el negocio

CVSS es un lenguaje común útil, pero por sí solo engaña. Un CVSS 6,5 en una API que expone datos personales de todos los clientes puede ser más urgente que un 9,0 en un sistema aislado sin datos. Un buen informe muestra:

La puntuación CVSS con el vector completo, para que puedas verificarla y recalcularla.
Una severidad ajustada al contexto que explique el impacto en tu negocio: datos expuestos, posible fraude, caída de servicio, exposición regulatoria.
La explotabilidad real: ¿se explotó de verdad o es teórica?

Desconfía de informes donde cada vulnerabilidad lleva la severidad que asignó la herramienta, sin análisis humano.

En la práctica, la clasificación de riesgo tiene dos capas. El rango de CVSS está estandarizado (bajo de 0,1 a 3,9; medio de 4,0 a 6,9; alto de 7,0 a 8,9; crítico de 9,0 a 10,0), pero la prioridad de corrección depende del contexto: qué dato está expuesto, cuántos clientes se ven afectados, si la explotación exige autenticación y si existe un control compensatorio. Dos hallazgos con la misma nota pueden requerir plazos muy distintos. Exige que el informe muestre ambas lecturas lado a lado, no solo la nota de la herramienta.

4. Hallazgos: evidencia, prueba de concepto y pasos de reproducción

Cada hallazgo debe permitir que tu equipo reproduzca el problema sin llamar al proveedor. Como mínimo:

Título e identificador estable, para seguirlo en la corrección y el reensayo.
Descripción de la falla y dónde está (URL, parámetro, función, componente).
Evidencia: capturas, peticiones y respuestas HTTP, salida de comandos, con datos sensibles enmascarados.
Pasos de reproducción numerados, en el orden en que se ejecutaron.
Impacto demostrado: qué consigue realmente un atacante con ese hallazgo, incluso encadenado con otros. Eso distingue un pentest de un escaneo; mira Escáner, pentest o bug bounty.
Precondiciones: ¿requiere autenticación? ¿Acceso a la red interna?

Para el auditor, la evidencia de explotación prueba que la prueba fue manual y que la falla es real, no un falso positivo.

Ejemplo ilustrativo de un hallazgo bien redactado

El ejemplo es ficticio y solo muestra el nivel de detalle esperado. No corresponde a ningún cliente real.

Campo	Contenido
Identificador y título	PM-004 — Acceso a pedidos de otros clientes cambiando el identificador en la API
Severidad	Alta (CVSS 8,1, vector completo en el anexo); ajustada a Crítica en contexto por exponer datos personales de todos los clientes
Dónde	`GET /api/v1/pedidos/{id}`, producción, versión probada indicada en el alcance
Precondición	Cuenta de cliente normal autenticada; sin acceso a la red interna
Evidencia	Petición y respuesta HTTP con datos enmascarados; captura de la respuesta con el pedido de otra cuenta
Reproducción	1) autenticarse como cliente A; 2) llamar al endpoint con el identificador de un pedido del cliente B; 3) observar la respuesta 200 con nombre, dirección y artículos
Impacto demostrado	Lectura de los pedidos de cualquier cliente enumerando el identificador, lo que constituye un incidente de datos personales
Corrección recomendada	Validar en el servidor que el pedido pertenece al usuario autenticado (control de acceso por objeto); identificadores no secuenciales como defensa adicional; pruebas automatizadas de autorización
Estado en el reensayo	Corregido: la llamada con el identificador de otro cliente devuelve 403; evidencia adjunta como PM-004-R1

Fíjate en lo que lo hace útil: tu equipo lo reproduce solo, el auditor ve explotación real y el estado del reensayo cierra el ciclo. Para entender esta clase de fallo, mira BOLA en APIs.

5. Recomendaciones de corrección que un desarrollador pueda aplicar

"Aplicar buenas prácticas de seguridad" no es una recomendación. Una corrección útil indica la causa raíz, qué cambiar (validación en el servidor, control de acceso por objeto, rotación de secretos), una referencia técnica y, cuando es posible, un ejemplo de código o configuración. También debe priorizar: qué corregir en días, qué puede esperar al siguiente ciclo y qué necesita una mitigación mientras llega la corrección definitiva.

6. Mapeo normativo

Si la prueba existe para cumplir un requisito, el informe debe decir cuál. En lugar de que el auditor adivine, una tabla de trazabilidad vincula la actividad del pentest con el requisito:

PCI DSS 4.0.1, requisito 11.4 (pentest interno y externo, segmentación, reensayo). Detalles en Pentest para PCI DSS 4.0.
ISO 27001, SOC 2 y RGPD, cuando formen parte de tu agenda de cumplimiento. Consulta Pentest para ISO 27001, SOC 2, RGPD y ENS.
La regulación sectorial que se aplique a tu organización.

El informe no sustituye el criterio de tu equipo legal o de cumplimiento sobre lo que la norma te exige, pero debe facilitar la respuesta.

Un ejemplo de tabla de trazabilidad que facilita el trabajo del auditor (los requisitos exactos dependen de tu norma y alcance):

Actividad del pentest	Dónde aparece	Requisito que apoya
Pruebas externas e internas con metodología nombrada	Sección de alcance y metodología	PCI DSS 4.0.1, requisito 11.4
Prueba de segmentación del entorno de tarjetas	Sección de segmentación	PCI DSS 4.0.1, requisito 11.4
Evidencia de explotación e impacto	Hallazgos	Exigencias de prueba independiente para entidades reguladas
Corrección y nueva verificación	Sección de reensayo	Requisitos de corrección documentada
Pruebas de control de acceso y protección de datos	Hallazgos de autorización y datos	Medidas de seguridad del RGPD (art. 32)

7. Reensayo: la prueba de que la corrección funcionó

El informe inicial muestra el problema; el reensayo muestra que desapareció. La sección de reensayo debe registrar la fecha, el estado de cada hallazgo (corregido, corregido parcialmente, no corregido, riesgo aceptado) y la evidencia de que el ataque original ya no funciona. Muchos auditores consideran que un informe sin reensayo deja el requisito abierto. Antes de firmar, pregunta al proveedor si el reensayo está incluido y en qué plazo.

8. Carta de atestación y resumen para terceros

Los clientes enterprise rara vez quieren el informe completo: detalla tus vulnerabilidades. Lo que piden es una carta de atestación (o resumen) que confirme quién probó, cuándo, el alcance, la metodología y el resultado general, sin exponer detalles técnicos. Confirma que el proveedor entrega ambos documentos: el informe técnico completo, de circulación restringida, y la carta para compartir.

Señales de alerta: el informe que es un volcado de escáner

Lista enorme de hallazgos sin priorización ni contexto.
Descripciones genéricas copiadas de bases públicas, iguales para cualquier cliente.
Sin evidencia de explotación ni pasos de reproducción.
Falsos positivos mezclados (una versión "vulnerable" que no es explotable en esa configuración).
Ninguna mención de lógica de negocio, control de acceso o encadenamiento de fallas.
Sin alcance, metodología ni limitaciones declaradas.
Sin sección de reensayo ni carta de atestación.

Checklist para recibir el informe

[ ] Resumen ejecutivo con veredicto y prioridades.
[ ] Alcance, ventana, enfoque y limitaciones declarados.
[ ] Metodología nombrada (OWASP, PTES, NIST SP 800-115).
[ ] CVSS con vector y severidad ajustada al negocio.
[ ] Cada hallazgo con evidencia, pasos de reproducción e impacto.
[ ] Recomendaciones específicas y priorizadas.
[ ] Mapeo a la norma que motivó la prueba.
[ ] Reensayo previsto, con plazo.
[ ] Carta de atestación para terceros.
[ ] Datos sensibles enmascarados y confidencialidad del documento definida.

Preguntas para el proveedor antes de firmar

¿Puedo ver un informe de ejemplo anonimizado antes de firmar?
¿Quién redacta y quién revisa el informe? ¿Hay revisión por una segunda persona?
¿El informe trae el vector CVSS completo y una severidad ajustada a mi negocio?
¿El reensayo está incluido? ¿Cuántas rondas y en qué plazo?
¿Recibiré la carta de atestación para mostrar a clientes?
¿Cómo se tratan, guardan y destruyen los datos sensibles hallados durante la prueba?
¿El informe asocia los hallazgos a la norma que motivó la prueba?

¿Quieres ver cómo se ve en la práctica?

Podemos enviarte un informe de ejemplo anonimizado para que lo compares con lo que entrega tu proveedor actual. Pídelo desde el formulario de presupuesto indicando que quieres el ejemplo; si ya tienes un alcance en mente, aprovecha para solicitar la propuesta.

Preguntas frecuentes

¿Cuántas páginas debe tener un informe de pentest?

No hay un número correcto. Depende del alcance y de los hallazgos. Importa más la estructura que la extensión: resumen ejecutivo corto, hallazgos con evidencia y reproducción, y anexos técnicos separados.

¿Se puede entregar el informe a clientes y auditores?

El informe técnico completo suele tener circulación restringida porque describe debilidades de tu entorno. Para terceros usa la carta de atestación o un resumen, y comparte el completo solo bajo acuerdo de confidencialidad.

¿Un escaneo de vulnerabilidades puede sustituir al informe de pentest?

No. El escaneo lista posibles fallas conocidas; el pentest las explota, las encadena y demuestra el impacto. Muchas normas y auditores esperan lo segundo.

¿Qué diferencia hay entre un informe de pentest y uno de escaneo?

El informe de escaneo lista posibles vulnerabilidades detectadas por una herramienta, normalmente con falsos positivos y sin prueba de explotación. El informe de pentest registra lo que un profesional logró explotar, encadenar y demostrar, con evidencia, impacto y corrección. Más en Escáner, pentest o bug bounty.

¿Cuánto tiempo debo conservar el informe?

Depende de la norma y de la política de tu empresa. Las entidades reguladas y los programas de cumplimiento suelen exigir conservar las evidencias varios años. Confirma el plazo con cumplimiento y guarda el informe y el reensayo juntos, con acceso restringido.

¿Quién debe recibir el informe dentro de la empresa?

El informe completo debe ir a un grupo pequeño y definido: CISO o responsable de seguridad, líderes técnicos que corrigen y, si hace falta, cumplimiento. Defínelo antes de la prueba, porque el documento describe cómo atacar tu entorno.

¿El reensayo está incluido en el informe?

Depende del contrato. Antes de firmar, confirma si el reensayo entra en el precio, cuántos ciclos y en qué plazo, y si el informe se reemite con el estado actualizado.

¿Cómo sé si las severidades son correctas?

Pide el vector CVSS completo y la justificación del impacto en tu negocio. Si la severidad parece venir solo de la herramienta, sin análisis, cuestiónala.