Si en el último servicio que contrataste recibiste un informe que parece una planilla de cálculo con identificadores CVE y una columna de severidad, lamentablemente no te hicieron un ejercicio de seguridad ofensiva real: te entregaron un análisis de vulnerabilidades.
La diferencia importa, tanto para tus organismos reguladores como para cualquiera que necesite detectar las brechas reales antes de que lo haga un actor de amenaza. Antes de llegar a tu CIO, a tu CISO o al directorio, el informe debe llegar a tu equipo de seguridad, que es quien actúa sobre él. Y un buen reporte no es una lista de hallazgos: es un activo estratégico. Describe cómo se atacó, traza la hoja de ruta para corregir y sirve como evidencia de diligencia lista para presentar ante el directorio.
A continuación, lo que separa a un informe de verdad de un simple listado, y cómo lo entregamos en Quarancle.
Empieza por el negocio, no por la lista de fallas
La primera página de un buen reporte es un resumen ejecutivo escrito para quien decide, no para el equipo técnico. Explica cuál fue el alcance, qué se logró comprometer, cuál es el riesgo para el negocio y qué debe pasar a continuación. Una persona sin perfil técnico debería poder leerlo y entender la amenaza.
Ese resumen también deja por escrito las reglas del engagement: qué entró en el alcance, qué quedó explícitamente fuera y bajo qué restricciones trabajó el equipo. Ese contexto es lo que vuelve interpretables los hallazgos.
Si la primera página es una tabla de vulnerabilidades y nada más, sin ese resumen, el entregable se estructuró para comodidad del proveedor y no para la tuya: obliga a tu equipo a traducir puntajes técnicos en las decisiones de negocio que el documento debería haber tomado por ti.
Muestra el camino del ataque, no solo el destino
Aquí es donde fallan la mayoría de los informes. Un hallazgo que dice "inyección SQL crítica en el portal de login" describe un destino. Lo que entrega un reporte serio es la narrativa del ataque: la reconstrucción, paso a paso, de cómo el equipo pasó del acceso inicial a los activos críticos.
Eso significa mostrar la cadena completa: el reconocimiento sobre información pública, el punto de entrada, la explotación técnica, la escalada de privilegios y el movimiento lateral por el entorno, documentados en secuencia y con prueba de concepto en cada etapa. Ese encadenamiento de hallazgos es lo que separa un ejercicio real de un escaneo automatizado: convierte un dato técnico en una historia que un CISO, un regulador o un equipo legal pueden seguir sin necesidad de un traductor.
Estándares como PTES y el OWASP Top 10 tratan el encadenamiento y la documentación del camino de ataque como requisitos base de una evaluación creíble. Un ejemplo de vector que suele quedar fuera es el robo de la cookie de sesión: el phishing moderno no siempre busca la contraseña, sino que se interpone entre el usuario y el servicio de autenticación para capturar la sesión ya emitida, evadiendo por completo el segundo factor. Si el reporte no dice si ese vector se probó y cómo respondió tu entorno, queda una brecha que ningún marco de cumplimiento detectará por ti.
No solo lo que falló: también lo que resistió
Las observaciones positivas no son relleno. Son la validación de que ciertos controles aguantaron bajo presión adversarial real, y es justo lo que el directorio necesita escuchar junto a las vulnerabilidades.
Un programa de seguridad maduro no se trata solo de encontrar lo que se rompió, sino de confirmar lo que funcionó, para saber sobre qué defensas construir. Si un proveedor solo entrega una lista de fallas, te está dando la mitad del cuadro.
Una hoja de ruta priorizada, no un listado por CVSS
Hay una diferencia real entre un plan de remediación por fases y una lista de correcciones ordenada por puntaje CVSS. Ordenar por CVSS prioriza la gravedad técnica, no lo que más expone a tu negocio, y esas dos cosas no siempre coinciden: la vulnerabilidad con mayor puntaje no es necesariamente la que un atacante usaría primero contra ti. Un CVSS por sí solo no le dice a un CISO qué hacer; el impacto de negocio, sí. Corregir rápido, además, no es solo un tema técnico, es financiero: los estudios de la industria, como el Cost of a Data Breach de IBM, muestran que contener una brecha antes reduce de forma significativa su costo. El tiempo medio de remediación (MTTR) es una métrica que el negocio debería apropiarse.
Un buen reporte segmenta los hallazgos en fases de corto, mediano y largo plazo, mapeadas a la prioridad del negocio y a los recursos disponibles. Cada hallazgo referencia la debilidad de fondo, por ejemplo con su CWE, para que el equipo de ingeniería entienda no solo qué corregir, sino por qué existe la falla y cómo evitar que reaparezca. Esa hoja de ruta es el documento que un CFO necesita para aprobar el gasto en seguridad; una lista de CVE no lo es.
También es la línea que separa un escaneo de una evaluación real: en una evaluación, un profesional revisa el resultado automatizado, descarta los falsos positivos y ordena la remediación por urgencia. Un escaneo por sí solo no hace ninguna de las dos cosas, y ningún reporte está completo sin dejar claras las exclusiones de alcance: qué no se probó y por qué.
Prueba que no se puede discutir
Los screenshots y los logs no son la prueba. La prueba es lo que esos screenshots muestran.
Prueba es el acceso de administrador a un panel interno logrado desde una cuenta sin privilegios. Es el registro de un cliente que se vuelve visible para otro a través de un identificador manipulable. Es un token de sesión que sigue vivo y evade el segundo factor. Y, para cada uno, son los pasos para reproducir el exploit, de modo que tu equipo pueda verificar la vulnerabilidad, validar la corrección y confirmar que no reaparece.
Sin ese nivel de documentación, el informe es una opinión. Con él, es una defensa técnica y regulatoria: evidencia de que se simuló un escenario de amenaza real, se identificaron exposiciones concretas y el negocio entendió qué estaba en riesgo. Marcos como NIST CSF 2.0 y PCI DSS exigen demostrar evidencia de pruebas y de remediación, no solo una declaración. La prueba de concepto no es un lujo: bajo varias exigencias de cumplimiento, es obligatoria.
El informe de Quarancle: en vivo, no un PDF que llega tarde
Todo lo anterior describe un buen informe. Pero incluso el mejor informe tradicional comparte un problema de fondo: es un PDF estático que llega al final, cuando el riesgo ya lleva semanas abierto.
En Quarancle el informe no es un documento que esperas, es el Quarancle Live Portal. Cada hallazgo aparece en tiempo real apenas un operador certificado lo valida y lo firma, con su severidad en CVSS 4.0, su CWE, la evidencia y los pasos de reproducción. Ves el nivel de riesgo del negocio actualizarse en vivo, la narrativa del ataque a medida que ocurre, la remediación priorizada por impacto, y marcas cada corrección para su re-test, sin esperar un archivo.
No entregamos papeleo. Entregamos, en vivo, lo que un informe debería ser: la prueba de lo que un atacante real podría hacer, y el camino claro para cerrarlo.