Hemos llegado a la última lección del Módulo 6, y a un punto que muchos técnicos subestiman: un informe excelente no sirve de nada si no se comunica bien. Documentamos los hallazgos (06-01), los clasificamos por riesgo con CVSS (06-02) y construimos una hoja de ruta de remediación (06-03). El trabajo escrito está terminado. Pero el objetivo final del pentest —ayudar a TechNova a reducir su riesgo— solo se cumple si la organización entiende, acepta y actúa sobre lo que hemos encontrado. Y eso pasa por las personas: la dirección que asigna presupuesto y los equipos técnicos que ejecutan las correcciones.

Esta lección trata de cómo presentar los resultados a públicos distintos, cómo se lee el resumen ejecutivo, cómo se conduce la reunión de cierre (debrief), cómo gestionar el tono para que sea constructivo y no culpabilizador, cómo usar métricas y comparación con estándares para dar contexto, y cómo hacer la entrega segura del informe y dejar claros los siguientes pasos, incluido el retest. Es la parte "blanda" del pentest, pero decide si todo lo técnico anterior se convierte en acción o se queda en un PDF olvidado en una carpeta.

1. Un mismo informe, dos públicos
2. El resumen ejecutivo
3. La reunión de cierre (debrief)
4. Tono: constructivo, nunca culpabilizador
5. Gestión de expectativas
6. Métricas y comparación con estándares
7. Entrega segura del informe
8. Siguientes pasos y retest
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

Ya vimos en 06-01 que el informe se estructura en dos bloques porque sirve a dos audiencias con necesidades opuestas. Al presentarlo, esa diferencia se vuelve crítica:

El error de principiante es dar la misma charla técnica a ambos: la dirección se pierde en la jerga y desconecta, y los técnicos se aburren con las generalidades. Adapta el mensaje al oyente, contando lo mismo con distinto nivel.

El resumen ejecutivo es la parte más leída del informe y la que decide si habrá presupuesto para remediar. Lo lee gente sin tiempo ni formación técnica, así que debe poder entenderse en pocos minutos y sin una sola línea de jerga. Qué contiene:

• Qué se hizo y con qué alcance: una frase sobre el engagement autorizado contra TechNova.
• Postura de seguridad global: una valoración honesta ("se identificaron debilidades graves que requieren atención prioritaria").
• Riesgos principales en lenguaje de negocio: los 3-5 hallazgos top traducidos a consecuencias (fuga de datos de clientes, parada de la tienda, incumplimiento).
• Un resumen visual: normalmente un recuento de hallazgos por severidad.
• La recomendación de más alto nivel: por dónde empezar y con qué urgencia.

Ejemplo de fragmento del resumen ejecutivo, en markdown, para TechNova:

Nota el tono: informa del riesgo con claridad y urgencia, pero sin dramatismo ni jerga. La dirección sale sabiendo qué está en juego y qué se le pide.

El debrief es la reunión donde el pentester presenta los resultados en persona. Es el momento de mayor valor comunicativo: permite matizar, responder dudas y alinear a todos. Una estructura eficaz:

Consejos para el debrief:

• Empieza por el contexto, no por el hallazgo más jugoso. Recuerda que fue un test autorizado con un alcance acordado.
• La cronología del ataque (la cadena de compromiso del Módulo 5) es tu mejor herramienta narrativa: contar cómo desde una SQLi se llegó al servidor interno y se pivotó a 10.10.10.0/24 hace tangible el riesgo mejor que cualquier tabla.
• Adapta la profundidad a quién esté en la sala. Si hay dirección y técnicos juntos, empieza a alto nivel y ofrece bajar al detalle cuando haga falta.
• Deja tiempo para preguntas. Muchas veces el cliente descubre en el debrief qué necesita realmente entender.

Este es quizá el punto más importante de la lección. Los hallazgos son fallos de alguien: un desarrollador que concatenó SQL, un administrador que dejó una contraseña débil. Si tu presentación suena a acusación, el equipo se pone a la defensiva, discute los hallazgos y la remediación se estanca. El objetivo es ayudar a TechNova a mejorar, no repartir culpas.

Contrasta el tono:

Habla de el sistema y el código, no de las personas. Enmarca cada hallazgo como una oportunidad de mejora con solución conocida. Reconoce también lo que TechNova hace bien: si el logging centralizado estaba bien montado o la segmentación funcionó, dilo. Un informe que solo señala lo negativo se percibe como injusto y pierde credibilidad.

Presentar bien incluye encuadrar correctamente qué es y qué no es un pentest, para que TechNova no saque conclusiones equivocadas:

• Un pentest es una foto en el tiempo, no una garantía permanente. "No encontramos X" no significa "X no existe"; significa que no se halló en el alcance y plazo acordados.
• Alcance y limitaciones: recuerda qué quedó fuera (sistemas, horarios, técnicas no permitidas por el RoE). Si un área no se probó, dilo con claridad para que nadie la crea "verificada".
• Cero hallazgos no es cero riesgo. Y muchos hallazgos no significa que TechNova sea "peor" que otros: significa que ahora sabe dónde están sus problemas, lo cual es una ventaja.
• La responsabilidad de corregir es del cliente. El pentester diagnostica y aconseja; TechNova ejecuta. Deja claras las expectativas sobre plazos y sobre el retest.

Gestionar expectativas evita dos reacciones opuestas y ambas malas: el pánico ("estamos perdidos") y la falsa tranquilidad ("ya nos auditaron, estamos seguros para siempre").

Los datos dan contexto y hacen la presentación más convincente y objetiva. Recursos útiles:

• Recuento por severidad y evolución respecto a auditorías anteriores (¿mejoró TechNova desde el último test?).
• Comparación con estándares y marcos: situar los hallazgos frente a referencias reconocidas —OWASP Top 10, CWE Top 25, controles CIS— da autoridad y ayuda al cliente a entender que sus problemas son categorías conocidas con soluciones conocidas.

Mapear cada hallazgo a un estándar convierte tu informe de "opinión de un consultor" en "estos son problemas del catálogo reconocido por la industria", lo que facilita que la dirección los tome en serio y que los técnicos encuentren guías de remediación establecidas.

El informe final es el documento más sensible del engagement: es un mapa exacto de cómo comprometer TechNova. Entregarlo mal puede causar más daño que las propias vulnerabilidades. Reglas de entrega:

• Canal cifrado y autenticado: nunca por correo sin cifrar. Usa un portal seguro, un fichero cifrado con contraseña compartida por otro canal, o cifrado de extremo a extremo.
• Solo destinatarios autorizados: las personas designadas en el contrato, nadie más.
• Marca de confidencialidad clara en el documento.
• Registro de entrega: deja constancia de a quién y cuándo se entregó.
• Retención y destrucción acordadas: conserva tu copia cifrada el tiempo pactado y destrúyela de forma segura al vencer, junto con la evidencia (enlaza con la gestión de evidencia de 06-01).

La entrega segura no es un trámite: es coherencia con todo lo que has predicado sobre confidencialidad durante el engagement.

Una buena presentación termina mirando hacia delante, no hacia el problema. Cierra siempre con acciones concretas:

• Priorizar la remediación según el roadmap de 06-03, empezando por los quick wins críticos.
• Fijar el retest: acordar cuándo el pentester volverá a verificar que los hallazgos corregidos ya no son explotables, cerrando el ciclo (recuerda los estados de retest de 06-03: corregido / mitigado / abierto / riesgo aceptado).
• Punto de contacto para dudas durante la remediación.
• Cultura de mejora continua: encajar el pentest como parte de un ciclo periódico, no como un evento aislado.

El retest es lo que transforma "sabemos qué está mal" en "confirmamos que lo arreglamos", y es la mejor prueba de que el pentest cumplió su objetivo: reducir el riesgo real de TechNova.

• Dar una charla técnica a la dirección. Se pierden y desconectan. Habla de riesgo de negocio y deja el detalle para los técnicos.
• Tono acusador. Culpar a personas pone al equipo a la defensiva y frena la remediación. Habla del sistema y del código, en clave de mejora.
• Solo malas noticias. Reconoce también lo que el cliente hace bien; da credibilidad y equilibrio.
• Prometer seguridad absoluta. Un pentest es una foto en el tiempo, no una garantía. Gestiona expectativas.
• Entregar el informe por un canal inseguro. Es un mapa de ataque; cífralo y contrólalo. Filtrarlo sería el peor final del engagement.
• Terminar sin siguientes pasos. Sin roadmap acordado ni retest, el informe se olvida. Cierra siempre con acciones y con una fecha de retest.
• Consejo: ensaya el debrief pensando "¿qué haría esta persona al salir de la sala?". Si la respuesta es clara y accionable para cada público, lo has hecho bien.

Ejercicio 1. Vas a presentar los resultados de TechNova en una reunión con el director general (no técnico) y el responsable de desarrollo (técnico). Describe cómo estructurarías la sesión y qué adaptarías del mensaje para cada uno, sin dar dos reuniones separadas.

Ejercicio 2. Reescribe estas tres frases de un borrador de debrief para que sean constructivas en lugar de culpabilizadoras: (a) "Vuestros desarrolladores no tienen ni idea de seguridad"; (b) "Es increíble que nadie se diera cuenta de esto"; (c) "Tenéis la peor seguridad que he visto".

Ejercicio 3. El responsable de TechNova quiere enviarte el informe final firmado por correo electrónico normal para "ir rápido" y reenviarlo a todo el equipo de IT. Explica qué le recomendarías y por qué, en términos de entrega segura y confidencialidad.

Solución 1. Estructura una sola sesión en capas: empieza con contexto y resumen ejecutivo a alto nivel (para el director: qué se hizo, postura global, riesgos de negocio, recomendación principal), usando la cronología del ataque para hacer tangible el riesgo sin jerga. Cuando el director tenga la foto, profundiza en el detalle técnico para el responsable de desarrollo: hallazgos concretos, reproducción y remediación, ofreciendo bajar al máximo detalle en los puntos que él necesite. Cierra con el roadmap y los siguientes pasos, relevantes para ambos. Adaptas el lenguaje (negocio vs. técnico) y el nivel de detalle, pero cuentas la misma historia coherente; así el director decide invertir y el técnico sabe qué ejecutar.

Solución 2. Reescrituras constructivas: (a) "El código de acceso a datos sigue patrones vulnerables comunes; con formación segura y consultas parametrizadas se corrige de raíz"; (b) "Es un fallo frecuente y fácil de pasar por alto; lo importante es que ahora está identificado y tiene solución conocida"; (c) "Hemos encontrado varias áreas de mejora prioritarias; con el plan propuesto se pueden abordar de forma ordenada, y hay controles que ya funcionan bien y conviene mantener". Todas hablan del sistema, no de las personas, y apuntan a la solución.

Solución 3. Le recomendaría no usar correo normal: el informe es un mapa exacto de cómo comprometer TechNova y el correo sin cifrar es un canal inseguro donde podría interceptarse o reenviarse sin control. En su lugar: entregarlo por un canal cifrado (portal seguro o fichero cifrado con la clave compartida por otro medio), solo a los destinatarios autorizados en el contrato, con marca de confidencialidad y registro de entrega. Reenviarlo "a todo el equipo de IT" amplía innecesariamente la exposición: debe limitarse a quien tenga necesidad real de conocerlo. La rapidez no justifica convertir el entregable de seguridad en una fuga de información.

Con esta lección cerramos el Módulo 6 y el ciclo completo de reporte: documentar (06-01), clasificar por riesgo (06-02), recomendar remediaciones (06-03) y ahora presentar los resultados para que se conviertan en acción. Aprendimos a servir a dos públicos con un mismo informe, a escribir un resumen ejecutivo sin jerga, a conducir la reunión de cierre apoyándonos en la cronología del ataque, y —lo más importante— a mantener un tono constructivo, nunca culpabilizador, porque el objetivo es ayudar a TechNova a mejorar, no señalar culpables. Añadimos la gestión de expectativas (un pentest es una foto en el tiempo), el uso de métricas y estándares como OWASP Top 10 para dar autoridad, la entrega segura del informe confidencial y los siguientes pasos, con el retest cerrando el ciclo y confirmando que el riesgo se redujo de verdad.

Aquí termina el trabajo de convertir el pentest en valor para el cliente: de la evidencia técnica capturada en el Módulo 5 hemos llegado a un informe presentado, entendido y accionable. A lo largo de todo el curso hemos usado un arsenal de herramientas —desde el reconocimiento hasta la explotación y el reporte— muchas veces de pasada. El Módulo 7: Herramientas y Recursos Adicionales vuelve sobre ese instrumental para conocerlo a fondo: la distribución Kali Linux, el framework Metasploit, los proxies de auditoría web Burp Suite y OWASP ZAP, y los recursos para seguir aprendiendo de forma continua. Terminado el método, es hora de dominar las herramientas que lo hacen posible.