Cómo estructurar un informe de pentest que aguante una auditoría

La mayoría de los informes de pentest están escritos para el interlocutor técnico que encargó la prueba. Funcionan bien durante las tres semanas siguientes a la entrega y se vuelven inservibles después, cuando aparece quien de verdad va a exprimirlos: un auditor externo, el comprador que revisa tu cuestionario de seguridad, o el abogado de la otra parte tras un incidente.

Ese lector no estuvo en la prueba, no conoce tu infraestructura, no tiene a quién preguntar y sólo dispone del PDF. Si el informe no le permite reconstruir qué se probó, cuándo, con qué permisos y qué se dejó fuera, no vale como evidencia. Vale como opinión.

El alcance se define por lo que quedó fuera

Casi todos los informes describen el alcance como una lista de objetivos: tantos rangos de IP, tantas aplicaciones. Eso es la mitad del trabajo. La mitad que falta —y la que pregunta siempre un auditor— es el alcance negativo.

Escribe explícitamente qué no se probó y por qué. Los motivos reales suelen ser mundanos y todos son legítimos si constan: el entorno de pagos estaba congelado por cierre de trimestre; el proveedor del SSO no autorizó pruebas sobre su tenant; la denegación de servicio se excluyó por contrato; el módulo de facturación se desplegó tres días después de cerrar la ventana.

Un informe que dice «se auditó la plataforma» sin acotar deja abierta la lectura de que todo lo no mencionado está limpio. Un informe que dice «no se probaron los endpoints /billing/* porque quedaron fuera de la ventana acordada del 4 al 15 de marzo» es más corto, más honesto y mucho más difícil de atacar.

Las condiciones de la prueba son parte del resultado

Un hallazgo sin sus condiciones de contorno no es reproducible, y lo que no es reproducible no es evidencia. Cada prueba necesita constar con:

• Ventana exacta, con fechas, horas y zona horaria. No «marzo de 2026».
• Origen del tráfico: las IP desde las que se probó. Es lo primero que pide el equipo de detección cuando quiere saber por qué no saltó nada.
• Cuentas y roles utilizados, identificados por nombre de usuario, con el rol exacto. «Usuario con privilegios» no dice nada; qa_auditor con rol project:viewer sí.
• Controles activos durante la prueba: si el WAF estaba en modo bloqueo, si había rate limiting, si se aplicó una lista blanca para el origen del test. Un pentest con la IP en lista blanca mide una superficie distinta de la que ve un atacante, y eso debe decirse.
• Diferencias entre el entorno probado y producción, si no se probó en producción. Versión, datos, integraciones desactivadas.

Este bloque cuesta media página y es el que evita la conversación más incómoda que existe: explicar dos años después por qué una vulnerabilidad explotada no aparecía en el informe.

La unidad mínima es el hallazgo, y necesita identidad estable

Un hallazgo debe poder citarse, seguirse y cerrarse por separado. Para eso necesita un identificador que no cambie entre versiones del informe ni entre campañas. Si en el informe de marzo el SQL injection del buscador es el FND-014 y en el de septiembre es el FND-003, has perdido la capacidad de demostrar que es el mismo problema y que llevaba seis meses abierto. Que es, exactamente, lo que el auditor quiere saber.

Cada hallazgo necesita, como mínimo:

• Identificador estable y título descriptivo del problema, no del síntoma.
• Activo afectado con precisión quirúrgica: FQDN, IP, puerto, ruta y parámetro.
• Versión o build del objetivo en el momento de la prueba.
• Fecha y hora del descubrimiento.
• Pasos de reproducción que otra persona pueda ejecutar sin llamarte.
• La petición y la respuesta completas, en texto seleccionable, no en captura.
• Impacto descrito en términos de lo que el atacante consigue, no de la categoría OWASP a la que pertenece.
• Valoración de riesgo con el método declarado y los vectores visibles.

Las capturas no son evidencia por sí solas

Una captura de pantalla demuestra que en algún momento alguien vio esa pantalla. No demuestra cuándo, ni contra qué sistema, ni con qué cuenta. Si vas a usar capturas, que incluyan la barra de direcciones completa, un reloj visible y el identificador de sesión o el usuario autenticado.

Mejor aún: acompaña cada captura de la traza en texto —petición HTTP cruda, salida de consola con marca de tiempo, hash del fichero obtenido—. El texto se puede verificar; la imagen sólo se puede creer.

El retest tiene que enlazar con el hallazgo original

El error más común de la fase de cierre es entregar el retest como un documento independiente que dice «se han corregido 14 de 17 hallazgos». Eso no sirve.

El retest necesita, hallazgo a hallazgo: el identificador original, la fecha de la reprueba, los mismos pasos de reproducción ejecutados otra vez, el resultado observado y el veredicto explícito —corregido, mitigado, aceptado como riesgo o persistente—. Si es «mitigado», di qué mitiga y qué queda expuesto. Si es «aceptado», identifica a la persona que lo aceptó y la fecha.

Esa cadena —hallazgo, corrección, reprueba, veredicto firmado— es lo único que convierte un informe en prueba de que el programa de seguridad funciona. Sin ella tienes una lista de problemas y una promesa.

Versiona el informe y protégelo de la edición silenciosa

Un informe que se corrige por correo y se reenvía como «v2 final buena» no tiene trazabilidad. Numera las versiones, deja constancia de qué cambió en cada una y quién lo aprobó, y calcula un hash del PDF entregado que puedas citar después. Si la organización usa firma electrónica, úsala: convierte una discusión sobre autenticidad en una comprobación de treinta segundos.

Cómo lo lee realmente un auditor

Por si sirve como lista de repaso, el recorrido típico de un auditor razonable es este: mira primero la fecha y el alcance, comprueba si el alcance cubre el sistema que él está auditando, busca las exclusiones, va al resumen de hallazgos abiertos, escoge dos y pide la evidencia de cierre de esos dos. Si los dos que escoge al azar están trazados de principio a fin, da por buena la muestra. Si uno de los dos no tiene fecha de reprueba, empieza a abrir todos los demás.

Escribe el informe pensando en ese recorrido y habrás resuelto el noventa por ciento del problema. El resto es disciplina: mismos identificadores, mismas plantillas, mismos campos obligatorios en todas las campañas. Es precisamente el tipo de consistencia que cuesta mantener a mano y que, en Violet Security, resolvemos obligando a que cada hallazgo nazca ya con su identificador, su activo y su traza de reprueba enganchados.