¿Cómo escribir un reporte de penetración que las empresas realmente entiendan?

Un reporte de penetración profesional traduce hallazgos técnicos en decisiones de negocio claras y priorizadas.

¿Alguna vez entregaste un trabajo muy completo y tu cliente dijo "no entendí nada"? Eso pasa en el 60% de los reportes de pentesting, según datos de SANS Institute. El problema no es que el hallazgo sea falso. El problema es que nadie sabe qué hacer con él.

Esta lección te enseña a construir un reporte que el director de TI de Liverpool y su abogado puedan leer sin necesitar un diccionario técnico.

El error más caro del pentester principiante

Imagina que encontraste una inyección SQL en el portal de proveedores de FEMSA. Documentes así: "Se detectó SQLi en el parámetro id_proveedor. Payload: ' OR 1=1 --".

¿Qué hace el lector con eso? Nada. No sabe si es grave, si hay que apagar el servidor esta noche o si puede esperar seis meses.

Un reporte sin contexto de impacto es como un diagnóstico médico que solo dice "hay bacterias". Técnicamente correcto, completamente inútil.

El 74% de las empresas medianas en México no corrigen vulnerabilidades críticas dentro de los 30 días posteriores al reporte, según el CERT-MX. La razón principal: el reporte no explica por qué importa.

La estructura que sí funciona: el Marco de Cuatro Capas

Un reporte profesional tiene cuatro secciones distintas, escritas para audiencias distintas. Llama a esto el Marco de Cuatro Capas.

Capa 1: Resumen Ejecutivo

Esta sección la lee el director general o el CFO. Máximo dos páginas. Sin términos técnicos.

Responde tres preguntas:

• ¿Cuál es el riesgo general para la empresa?
• ¿Cuántos hallazgos críticos, altos, medios y bajos se encontraron?
• ¿Cuál es la acción más urgente?

Ejemplo real para una empresa como Bimbo: "Se realizó una prueba de penetración del 3 al 7 de marzo de 2025 sobre el portal de distribuidores. Se encontraron 2 vulnerabilidades críticas que permiten acceso no autorizado a datos de $1,200,000 en pedidos activos. Se recomienda suspender el acceso externo al módulo de carga masiva hasta aplicar el parche."

Eso sí lo entiende un director. En dos oraciones sabe el problema, el costo potencial y la acción.

Capa 2: Alcance y metodología

Aquí explicas qué probaste y cómo. Esto protege legalmente a ambas partes.

Incluye:

• Sistemas en alcance (IPs, URLs, aplicaciones)
• Sistemas fuera de alcance
• Fechas y horarios de las pruebas
• Metodología usada (OWASP, PTES, NIST SP 800-115)
• Tipo de prueba: caja negra, caja gris o caja blanca

Esta sección es tu respaldo ante el SAT o ante el INAI si alguien cuestiona la prueba. Sin ella, tú puedes ser el acusado.

Capa 3: Hallazgos detallados

Aquí vive el contenido técnico. Cada hallazgo sigue el mismo formato:

1. Nombre del hallazgo: descriptivo, no solo el CVE
2. Severidad CVSS: número y categoría
3. Descripción: qué es la vulnerabilidad
4. Evidencia: captura de pantalla, payload, respuesta del servidor
5. Impacto de negocio: qué puede perder la empresa en pesos o en reputación
6. Recomendación: pasos concretos para corregir

Ejemplo de hallazgo bien documentado:

Hallazgo: Inyección SQL en módulo de proveedores Severidad CVSS 3.1: 9.8 (Crítica) Descripción: El parámetro id_proveedor no valida la entrada del usuario. Un atacante puede extraer toda la base de datos con una sola petición. Evidencia: Payload ' UNION SELECT tabla, columna FROM information_schema.tables -- devolvió 47 tablas incluyendo tbl_pagos y tbl_usuarios. Impacto: Exposición de datos de $8,500,000 en cuentas por pagar. Posible multa del INAI de hasta $23,000,000 por filtración de datos personales de proveedores. Recomendación: Implementar consultas parametrizadas en el ORM. Aplicar principio de mínimo privilegio al usuario de base de datos. Tiempo estimado de corrección: 3 días de desarrollo.

¿Ves la diferencia? El director sabe que hay $23,000,000 en riesgo. El desarrollador sabe exactamente qué cambiar.

Cómo usar CVSS sin confundir a nadie

El sistema CVSS (Common Vulnerability Scoring System) da una puntuación del 0 al 10 a cada vulnerabilidad. Pero si solo escribes "CVSS 7.5" sin explicar qué significa, nadie actúa.

Usa esta tabla como referencia y explícala en tu reporte:

Cuando le dices a Mercado Libre que su vulnerabilidad es CVSS 9.8 y que deben actuar en 24 horas, eso es una instrucción operativa. Ya no es solo información.

El 88% de las organizaciones que reciben recomendaciones con plazos específicos las implementan dentro del tiempo sugerido, según Ponemon Institute. El plazo convierte el dato en compromiso.

Capa 4: Apéndices técnicos

Aquí pones todo lo que el equipo técnico necesita pero que abruma al ejecutivo. Logs completos, salidas de Nmap, capturas de Burp Suite, scripts usados.

El apéndice también incluye la metodología de reproducción: pasos exactos para que el desarrollador replique la vulnerabilidad en su entorno y confirme que el parche funcionó.

El lenguaje que cierra contratos

Hay una diferencia entre un reporte que se archiva y uno que genera acción. La diferencia está en el vocabulario.

Evita esto:

• "Se encontró una vulnerabilidad de tipo XSS reflejado en el campo de búsqueda."

Escribe esto:

• "Un atacante puede robar la sesión activa de cualquier empleado de Liverpool con un solo clic en un enlace malicioso. Esto incluye acceso a los paneles de administración de inventario valorados en $45,000,000."

La segunda versión activa el nervio del tomador de decisiones. Describe la película, no el tecnicismo.

Errores comunes que invalidan un reporte

Existen cuatro errores que vuelven inútil un reporte, sin importar qué tan buena fue la prueba.

Error 1: No incluir evidencia reproducible. Si escribes "se detectó acceso no autorizado" sin mostrar cómo, el equipo técnico no puede confirmar ni corregir nada.

Error 2: Usar jerga sin definirla. Palabras como "payload", "fuzzing" o "enumeration" deben definirse la primera vez que aparecen. El director jurídico también lee el reporte.

Error 3: Reportar sin priorizar. Si listas 40 hallazgos con el mismo peso visual, el cliente no sabe por dónde empezar. Usa una tabla de resumen con severidades al inicio.

Error 4: Omitir el contexto regulatorio mexicano. Una filtración de datos personales activa la Ley Federal de Protección de Datos Personales en Posesión de Particulares. El INAI puede multar hasta $23,000,000. Mencionarlo no es alarmismo: es información que el cliente necesita para calcular su riesgo real.

De hallazgo a decisión: el ciclo completo

Un buen reporte no termina cuando lo entregas. Incluye una reunión de presentación de resultados donde explicas los hallazgos críticos cara a cara.

En esa reunión, presenta primero el resumen ejecutivo. Luego pregunta: "¿Quieren ver la evidencia técnica de los hallazgos críticos?" Así controlas el ritmo y demuestras que entiendes a tu audiencia.

Las empresas como FEMSA o Bimbo tienen comités de seguridad que se reúnen cada trimestre. Si tu reporte llega en el formato correcto, puede entrar directamente a agenda. Si llega como un PDF de 80 páginas sin resumen, va al cajón.

Documentar bien es la diferencia entre un pentester que hace la prueba una vez y uno al que llaman cada año.