Retest de pentest: qué es, por qué lo exige el auditor y con qué frecuencia probar

El problema: salió el informe, la corrección "se hizo" y nadie lo comprobó

Un pentest termina con una lista de fallos. El valor real llega después: el equipo corrige y alguien tiene que demostrar que la corrección funciona. Eso es lo que hace el retest. Sin él, tienes un informe que dice "había un problema" y ninguna evidencia de que haya desaparecido.

Piensa en lo que ocurre en la práctica. El informe llega con doce hallazgos. El equipo abre doce tickets, cierra once en dos sprints y deja uno "para después". Seis meses más tarde, el auditor pregunta: "¿cuál es el estado de aquellos hallazgos?". La respuesta honesta es "creemos que se corrigieron". Para un auditor, creer no es evidencia.

Auditores, QSA y áreas de riesgo lo saben. Por eso el retest aparece como punto separado en las conversaciones de cumplimiento, y es donde más informes se quedan incompletos. En esta guía explicamos qué es, qué debe entregar, qué correcciones suelen fallar, con qué frecuencia probar y qué preguntar al proveedor antes de firmar.

Qué es un retest

El retest es la repetición dirigida de las pruebas que originaron cada hallazgo, una vez que el equipo aplicó la corrección. El pentester reproduce el mismo ataque en las mismas condiciones y registra si todavía funciona.

No es un nuevo pentest. El alcance se limita a los hallazgos ya reportados: no busca vulnerabilidades nuevas, no cubre funcionalidades que cambiaron después y no sustituye a la prueba anual. Ese límite ayuda a las dos partes: el cliente sabe exactamente qué paga y el proveedor sabe exactamente qué debe demostrar.

	Pentest	Retest
Objetivo	Descubrir qué es explotable	Confirmar que lo encontrado fue corregido
Alcance	Aplicación, red o entorno completo	Solo los hallazgos del informe anterior
Resultado	Lista de hallazgos con evidencia	Estado por hallazgo con nueva evidencia
Esfuerzo típico	Días o semanas, según el alcance	Una fracción de la prueba original, proporcional al número de hallazgos
Cuándo	Anual y tras cambios relevantes	Tras la corrección, en una ventana acordada

El ciclo de vida de un hallazgo

El retest solo tiene sentido dentro de un ciclo. Cada hallazgo recorre las mismas etapas, y cada etapa deja un registro que el auditor puede seguir:

Etapa	Qué ocurre	Registro que queda
1. Descubrimiento	El pentester explota el fallo y documenta la evidencia	Hallazgo en el informe, con severidad y pasos de reproducción
2. Triaje	El equipo define responsable, plazo y enfoque de corrección	Ticket vinculado al ID del hallazgo
3. Corrección	Se cambia el código, la configuración o el proceso	Commit, pull request o solicitud de cambio
4. Retest	El pentester repite el ataque original en producción	Petición, respuesta o log nuevos
5. Estado	El hallazgo se cierra, se reabre o se acepta como riesgo	Informe actualizado con estado y fecha

Si falta cualquier etapa, el ciclo se rompe. El error más común es saltar de la etapa 3 directamente al cierre del ticket, sin la etapa 4: el fallo "desaparece" del backlog, pero nadie verificó el entorno.

Por qué auditores y reguladores esperan retest

En PCI DSS 4.0, el requisito 11.4 trata el pentest como un ciclo y no como un evento: las vulnerabilidades explotables encontradas deben corregirse y la prueba repetirse para verificar la corrección. Mira cómo encaja en el informe en Pentest para PCI DSS 4.0.

En el sector financiero brasileño, la normativa del Banco Central espera que la institución trate lo que la prueba encuentra y pueda demostrarlo ante el supervisor. Un retest documentado es la forma más directa de hacerlo. Revisa el texto vigente de las resoluciones aplicables a tu tipo de institución antes de armar el paquete de evidencias.

La lógica es la misma en ISO 27001 y SOC 2: el auditor no solo quiere saber que probaste, sino que la gestión de vulnerabilidades cerró el ciclo. Y vale también para el cuestionario de seguridad de un cliente enterprise: "¿corrigieron lo que encontró el pentest?" es una pregunta que el retest responde con un documento, no con una promesa.

Qué muestra un informe de retest

Un buen retest devuelve, para cada hallazgo original:

1. Identificador y severidad originales, para poder rastrearlos contra el informe anterior.
2. Estado: corregido, parcialmente corregido, no corregido o riesgo aceptado (este último con justificación y aprobación formal de la empresa).
3. Evidencia nueva: la petición y la respuesta, la captura o el log que muestran que el ataque original falla (o sigue funcionando).
4. Fecha y responsable de la prueba, para la pista de auditoría.
5. Nuevos hallazgos introducidos por la corrección, cuando son evidentes, registrados aparte.

Un retest que solo dice "todos los fallos fueron corregidos" no sirve como evidencia. Quien lo lee necesita ver qué se intentó. La tabla siguiente resume qué exige cada estado para que un auditor lo acepte:

Estado	Significado	Evidencia necesaria
Corregido	El ataque original y las variaciones razonables fallan	Petición y respuesta que muestran el fallo del ataque, fecha y entorno probado
Parcialmente corregido	El vector original falla, pero una variación o instancia aún funciona	Evidencia de lo que ahora falla y de lo que sigue siendo explotable
No corregido	El ataque original sigue funcionando	Evidencia de la explotación repetida y del impacto actual
Riesgo aceptado	La empresa decidió convivir con el fallo	Justificación, control compensatorio, aprobación formal y fecha de revisión
No aplicable	El componente fue desactivado o retirado	Prueba de la retirada, no solo sacar el hallazgo del alcance

Cuándo hacer el retest

El mejor momento es justo después de que el equipo marque las correcciones como desplegadas en producción (o en el entorno equivalente). Volver a probar en preproducción puede servir como chequeo previo, pero solo la verificación en el entorno real demuestra el resultado final.

Acuerda una ventana con el proveedor: por ejemplo, que acepte solicitudes de retest durante un período tras la entrega del informe. Pregúntalo al contratar. Una ventana demasiado corta obliga a corregir con prisa; sin ventana, el retest se convierte en un presupuesto nuevo.

Dos consejos de calendario ayudan mucho. Primero, agrupa las correcciones en lotes en vez de pedir un retest por hallazgo: el proveedor trabaja con más eficiencia y tú pasas por menos rondas. Segundo, trabaja hacia atrás desde la fecha de tu auditoría o supervisión: si el informe final actualizado debe estar listo en marzo, la ventana de corrección termina bastante antes.

Errores comunes al corregir

Son los patrones que más veces hacen que un hallazgo vuelva como "no corregido":

• Corregir el síntoma, no la causa. Bloquear el payload de la prueba en vez de arreglar la validación. El pentester cambia una coma y el fallo vuelve.
• Resolver solo con WAF. Una regla en el WAF reduce el riesgo inmediato, pero no elimina la vulnerabilidad de la aplicación. Vale como mitigación temporal y debe registrarse como tal.
• Validar solo en el cliente. Ocultar un botón o comprobar un campo en el navegador no detiene a quien llama a la API directamente. La regla tiene que existir en el servidor.
• Corregir una instancia y olvidar la clase. El mismo fallo de autorización en cinco endpoints, corregido en uno. BOLA en APIs es el ejemplo clásico: la corrección correcta es un control central, no cinco parches.
• Introducir una regresión. La corrección rompe otra protección, o una versión posterior reintroduce el fallo. Un test automatizado para el caso corregido evita que el hallazgo vuelva.
• Cambiar el alcance para que el hallazgo desaparezca. Sacar un sistema del informe no es corregir, y el auditor lo nota por el diagrama de red.
• Corregir sin registrar. Sin ticket, commit o changelog, el equipo no puede explicar qué cambió.

Con qué frecuencia hacer pentest

La norma de mercado, y lo que esperan PCI DSS y la mayoría de los auditores, es al menos una vez al año y después de cualquier cambio significativo: nueva funcionalidad crítica, migración de nube, cambio de proveedor de autenticación, integración con terceros, cambio de arquitectura. Para instituciones reguladas por el Banco Central de Brasil, la periodicidad mínima viene de la norma aplicable; confirma el texto vigente y trata lo anual como un piso, no como un techo.

Si vendes a clientes enterprise, el informe debe ser reciente. Un pentest de 2023 presentado en 2026 tras dos migraciones suele ser rechazado.

Una cadencia basada en el riesgo suele funcionar mejor que una fecha fija en el calendario:

Situación	Cadencia sugerida
Base	Pentest completo anual, con retest tras las correcciones
Cambio significativo (autenticación, pagos, exposición de datos, nueva arquitectura)	Prueba enfocada en el cambio, antes o justo después del lanzamiento
Activos de alto riesgo (APIs públicas, entorno de tarjetas, datos sensibles)	Ciclos más cortos, definidos por el análisis de riesgo de la empresa
Entre pruebas	Escaneo continuo y tests automatizados en CI para detectar regresiones

Las herramientas automatizadas en el pipeline complementan el pentest, pero no lo sustituyen. Encuentran rápido clases conocidas de fallos; la prueba manual encuentra fallos de lógica de negocio y encadenamientos que ningún escáner ve. La diferencia está en ¿Escáner, pentest o bug bounty?.

Qué preguntar al proveedor

Antes de firmar, confirma por escrito:

• ¿El retest está incluido en el precio o se cobra aparte?
• ¿Cuántas rondas de retest incluye? Una suele bastar si las correcciones son buenas; dos dan margen real.
• ¿Cuál es la ventana para solicitarlo y qué pasa cuando se cierra?
• ¿El informe final se actualiza con el estado de cada hallazgo, o el retest es un documento separado?
• ¿El retest se hace en producción y entrega evidencia nueva por cada hallazgo?
• ¿Quién lo ejecuta: el mismo equipo de la prueba original?
• ¿Cómo se tratan los hallazgos que la corrección dejó parcialmente abiertos?

Lo que cambia el costo de un retest suele ser el número de hallazgos, la complejidad de reproducir cada uno y el número de rondas, no un valor fijo universal. Por eso conviene pedir la política por escrito en lugar de comparar solo el precio de la prueba inicial. Más preguntas para comparar propuestas están en 10 preguntas antes de contratar un pentest, y el efecto del retest en el precio en ¿Cuánto cuesta un pentest?.

Cómo trata el retest Pentest Machine

El retest está incluido en nuestros paquetes. Cada hallazgo vuelve con estado y evidencia nueva, y el informe final se actualiza para reflejar el estado posterior a la corrección. Si tu auditoría o supervisión está en el calendario, lo ideal es cerrar alcance y ventana de retest antes de que empiece la prueba. Pide un presupuesto e indica tu fecha de cumplimiento.

Preguntas frecuentes

¿Un retest es lo mismo que un nuevo pentest?

No. El retest verifica solo los hallazgos ya reportados, con el mismo método. Un nuevo pentest busca fallos nuevos en todo el alcance. Se complementan: el pentest descubre, el retest prueba la corrección.

¿Cuánto después de la corrección debo hacer el retest?

En cuanto las correcciones estén en producción. Acuerda con el proveedor una ventana de solicitud para no perder el plazo y agrupa las correcciones en lotes para reducir el número de rondas.

¿Cuántas rondas de retest necesito?

Depende del número de hallazgos y de la calidad de las correcciones. Pregunta cuántas rondas incluye y qué pasa si una corrección falla. Una ronda suele bastar para correcciones bien hechas; una segunda da margen para ajustes.

¿Basta un WAF para dar un hallazgo por corregido?

En general no. El WAF mitiga, pero la vulnerabilidad sigue en la aplicación. El informe debe registrarlo como mitigación, no como corrección, y el hallazgo sigue abierto hasta tratar la causa.

¿Puede hacer el retest mi equipo interno?

Puede, como chequeo previo. Para auditoría y cumplimiento, en cambio, vale el retest ejecutado por quien hizo la prueba original o por un tercero independiente, con evidencia documentada. Quien corrigió no debería ser el único que valida.

¿Qué pasa con un hallazgo que la empresa decide no corregir?

Pasa a riesgo aceptado, con justificación, control compensatorio, aprobación formal de la dirección y fecha de revisión. El retest registra ese estado en lugar de fingir que el hallazgo se resolvió.

¿Con qué frecuencia debo hacer pentest?

Al menos una vez al año y tras cambios significativos en la aplicación o la infraestructura, con retest después de cada ronda de correcciones. Los entornos regulados deben confirmar la periodicidad en la norma aplicable.