Cómo reconocer un buen informe de pentest

Cuando contratas un pentest, lo que realmente compras no son las horas de trabajo ni las herramientas que se usaron — es el informe. Ahí es donde se nota la diferencia entre una evaluación real y un escaneo automático con un PDF genérico pegado encima. Y como cliente casi nunca tienes forma de comparar, porque es raro recibir más de un informe de pentest en la vida de una empresa. Esta es la guía de qué buscar.

Cada hallazgo debería responder cuatro preguntas

Da igual cuántas páginas tenga el informe si cada hallazgo no deja claro esto:

• ¿Qué pasa, exactamente? No "posible vulnerabilidad de control de acceso", sino algo como: "un usuario autenticado puede cambiar un número en la URL y ver los datos de otro cliente, sin ninguna verificación de que le pertenecen".
• ¿Qué significa para el negocio, no solo para el sistema? El detalle técnico importa, pero lo que decide si esto se arregla esta semana o el próximo trimestre es el impacto real: ¿se expone información de clientes? ¿hay una obligación legal de reportarlo? ¿alguien podría usarlo para hacer fraude?
• ¿Cómo se reproduce? Un hallazgo sin pasos claros — la URL exacta, qué se cambió, qué se esperaba ver y qué se vio en realidad — no se puede validar ni volver a probar después del fix. Si tu equipo técnico no puede reproducirlo en cinco minutos leyendo el informe, algo falta.
• ¿Cómo se arregla, específicamente? "Sanitizar las entradas" no es una recomendación, es una frase que suena a recomendación. Una remediación real dice qué librería, qué configuración, qué línea de defensa agregar — no deja la tarea de investigar cómo arreglarlo en manos de quien lo recibe.

Señales de que el informe promete más de lo que prueba

Algunas cosas que, si las ves, valen la pena preguntar antes de dar el proyecto por cerrado:

• Severidad sin justificación. Si un hallazgo dice "crítico" pero no explica por qué (¿requiere estar autenticado? ¿solo funciona en un ambiente que no es producción?), la severidad puede estar inflada — o subestimada, lo que es peor.
• Todo mezclado en un párrafo. Un informe serio separa cada vulnerabilidad como una unidad propia, con su propio título, evidencia y remediación — no las agrupa todas bajo "problemas de seguridad encontrados".
• Cero contexto de por qué importa. Un XSS reportado sin explicar qué puede hacer un atacante con él (¿robar la sesión de un administrador? ¿cambiar una contraseña?) deja al lector adivinando si es grave o cosmético.
• Nada de retest. Si el proveedor no ofrece verificar que lo corregido quedó realmente corregido, el informe es un punto de partida sin cierre — corregiste algo, pero nadie confirmó que funcionó.

Por qué esto no es solo un detalle de formato

Un informe bien escrito es lo que le permite a tu equipo técnico actuar sin tener que adivinar, y a la gerencia priorizar sin tener que confiar a ciegas en una etiqueta de color. Nuestra metodología sigue PTES y OWASP Testing Guide precisamente porque son marcos que obligan a esa disciplina en cada hallazgo — no un checklist que se corre una vez y se olvida. Si quieres entender primero qué tipos de vulnerabilidad son las más comunes, acá explicamos el OWASP Top 10 sin jerga, y si ya tienes un hallazgo puntual y necesitas entender qué tan grave es, nuestra calculadora CVSS te da el puntaje en segundos.