Retests ilimitados en pentest: estándar

Respuesta directa: Los retests ilimitados son esenciales porque sin ellos, las vulnerabilidades "corregidas" nunca se verifican de forma independiente. El ciclo de seguridad está roto si termina en el hallazgo. Un pentest sin retests incluidos es como una revisión médica sin seguimiento: útil, pero incompleta.

El problema que nadie menciona en el contrato

Cuando contratas un pentest, el proveedor típicamente hace lo siguiente: ejecuta las pruebas, entrega el informe y… cierra el proyecto. Si quieres que vuelvan a verificar si corregiste una vulnerabilidad crítica, hay dos escenarios comunes:

Escenario A: el contrato no menciona retests. Cuando los solicitas, recibes una nueva propuesta económica de $2,000 a $10,000 por "retest de alcance limitado". Para saber exactamente qué debe incluir el reporte de cada retest, consulta la guía sobre cómo se ve un buen reporte de pentesting.

Escenario B: el contrato permite "1 ronda de retests" en los 30 días posteriores a la entrega. Si tu equipo tarda más en corregir (cosa que pasa con mucha frecuencia), el derecho vence.

Ambos escenarios tienen el mismo efecto práctico: las organizaciones no solicitan retests. Ya sea por costo, por fricción, o porque el plazo venció. El resultado es que vulnerabilidades marcadas como "en remediación" en un Excel quedan abiertas en producción durante meses.

Datos que confirman el problema

Según el Ponemon Institute (2024), solo el 34% de las organizaciones verifica activamente que sus remediaciones cerraron las vulnerabilidades identificadas en pentests.
El SANS Institute reporta que el tiempo promedio de remediación de una vulnerabilidad crítica supera los 60 días para organizaciones sin procesos automatizados. La mayoría de los contratos de pentest ofrecen retests válidos por 30 días.
Según datos de Veracode (2024), el 68% de las aplicaciones tienen vulnerabilidades que permanecen abiertas por más de 90 días después de ser identificadas.

Estos números no son una coincidencia: son el resultado directo de un modelo donde verificar la remediación tiene un costo adicional.

Por qué los retests son parte del proceso, no un extra

El pentest no termina cuando se entrega el informe. El proceso completo tiene cuatro etapas:

Identificar → Reportar → Remediar → Verificar

Si la cuarta etapa no ocurre, el proceso está truncado. Es como si un auditor financiero identificara irregularidades contables, las reportara, y luego no pudiera verificar si la empresa las corrigió sin pagar una factura adicional.

El ciclo virtuoso que los retests permiten

Cuando los retests son ilimitados e incluidos:

El equipo de desarrollo tiene incentivos para pedir verificación: no hay fricción económica ni burocrática
El pentester puede confirmar que el fix es correcto: no solo que el síntoma desapareció, sino que el problema raíz fue resuelto
Se detectan regresiones: a veces un fix en un lugar rompe algo en otro lado
El historial queda documentado: el informe final refleja el estado real de seguridad, no el estado al momento del testing inicial

La táctica de los "retests incluidos con límite"

Algunos proveedores ofrecen "retests incluidos" pero con restricciones que los hacen prácticamente inútiles:

Restricción común	Impacto real
Solo 30 días después de la entrega	Los equipos rara vez terminan de remediar en 30 días
Solo para hallazgos críticos y altos	Las medias y bajas nunca se verifican
Máximo 1 ronda de retests	Si el fix inicial no funciona, ya no hay verificación
Solo por el mismo equipo que ya no está disponible	Los pentesters fueron asignados a otros proyectos
Requiere nuevo scoping y aprobación	La burocracia interna elimina la solicitud

Los retests verdaderamente ilimitados no tienen ninguna de estas restricciones: cualquier hallazgo, en cualquier momento del contrato, puede solicitarse para retest.

Cómo solicitar retests ilimitados en un RFP

Cuando evaluás proveedores de pentesting, estas son las preguntas que debes hacer explícitamente:

Preguntas obligatorias sobre retests

"¿Los retests están incluidos en el precio?" — No aceptes "sí, tenemos un proceso de retests" sin confirmar que no hay costo adicional.
"¿Cuántos retests puedo solicitar?" — Si la respuesta tiene un número o un límite de tiempo, no son ilimitados.
"¿Hay un plazo de vencimiento para solicitar retests?" — Un contrato de 12 meses debería permitir retests durante todo ese período.
"¿Los retests los ejecuta el mismo pentester que encontró la vulnerabilidad?" — Idealmente sí, porque tiene contexto del hallazgo original.
"¿Cómo se documenta la verificación de remediación en el informe?" — Debe quedar registro de evidencia antes y después.

Cláusula recomendada para incluir en contratos

"El proveedor se compromete a ejecutar retests ilimitados sobre cualquier hallazgo identificado en el alcance contratado, durante la vigencia del contrato. Cada retest incluirá evidencia técnica documentada de la verificación de remediación."

Red flags en propuestas de pentest

Señales de alerta que indican que los retests serán un problema:

El precio de retests no está mencionado en la propuesta (ni incluido ni excluido)
La propuesta ofrece "1 ronda de retests dentro de los 30 días"
El proveedor responde "los retests se cotizan por separado según el alcance"
No hay mención de cómo se documenta la verificación de remediación
El contrato tiene una cláusula de "proyecto cerrado" tras la entrega del informe

El impacto real: un escenario típico sin retests

Una empresa de SaaS recibe un pentest que identifica 12 vulnerabilidades: 2 críticas, 5 altas, 3 medias, 2 bajas. El equipo de desarrollo trabaja durante 6 semanas para corregirlas. Pero:

Una de las vulnerabilidades críticas fue mal corregida: el síntoma desapareció pero el vector de ataque original sigue existente
Dos vulnerabilidades altas no fueron corregidas porque el equipo las confundió con issues similares en el backlog
El proveedor de pentest no puede verificar porque el contrato venció y un nuevo retest cuesta $5,000

El resultado: la empresa cree que su postura de seguridad mejoró significativamente, pero en realidad sigue expuesta a las vulnerabilidades más críticas. Esto no es hipotético — es el escenario más común en organizaciones que contratan pentesting sin retests incluidos.

Estándares de la industria que lo respaldan

El PTES (Penetration Testing Execution Standard) define explícitamente una fase de Post-Exploitation / Reporting que incluye la verificación de remediaciones como parte del proceso completo. El OWASP Testing Guide también incluye la verificación de fixes como parte del ciclo de testing. Para entender el modelo completo en el que los retests ilimitados son un componente central, consulta la guía sobre qué es el PTaaS y cómo funciona.

Ningún estándar de la industria contempla que el proceso termine en la entrega del informe. El retesting es parte inherente del proceso — no un servicio opcional.

El estado real de las remediaciones: datos de la industria 2026

El State of Pentesting Report 2026 de Cobalt.io analiza más de 10,000 hallazgos y revela datos concretos sobre el ciclo de remediación real. Solo el 52% de los hallazgos totales llega a ser resuelto, aunque el 86% de los hallazgos de alto riesgo se abordan dentro del mismo engagement. Una parte significativa de hallazgos de riesgo medio y bajo queda abierta indefinidamente.

Más relevante: el 15–20% de los hallazgos de alto riesgo siguen siendo explotables en el primer retest, incluso cuando el equipo de desarrollo creía haber corregido el problema. El fix inicial resolvió el síntoma visible pero no el vector de ataque subyacente. Sin un retest independiente, esa vulnerabilidad queda documentada como "corregida" cuando en realidad sigue siendo explotable.

El tiempo mediano de remediación para vulnerabilidades de perímetro supera los 32 días según datos de Verizon DBIR citados por múltiples proveedores del sector. Este dato es crítico: la mayoría de los contratos de pentest limitan los retests a 30 días desde la entrega del informe. Por definición, un contrato con retests limitados expira antes de que la remediación promedio esté completa.

Retests y cumplimiento normativo: lo que exigen los auditores

Los marcos de cumplimiento más comunes no solo recomiendan pentesting — exigen evidencia de que los hallazgos fueron corregidos y verificados. Esta distinción es relevante para organizaciones que buscan certificaciones:

SOC 2 Type II: Los auditores no se conforman con un reporte de pentest. Solicitan evidencia del estado de remediación de los hallazgos críticos y altos. Un reporte que diga "hallazgo corregido" sin evidencia de retest no satisface el criterio de due diligence de la mayoría de los auditores.

ISO/IEC 27001:2022: El control A.8.8 (gestión de vulnerabilidades técnicas) y los controles del Anexo A relacionados con pruebas de seguridad exigen que las correcciones sean validadas. La certificación no se obtiene demostrando que se encontraron vulnerabilidades — se obtiene demostrando que se corrigieron y que existe un proceso de verificación documentado.

PCI-DSS v4.0 (Requisito 11.3): El estándar de seguridad de datos para pagos exige pentesting anual con evidencia de que los hallazgos fueron remediados. El requisito 11.3.2 cubre específicamente el retesting posterior a correcciones para vulnerabilidades de riesgo alto.

Para organizaciones que buscan estas certificaciones, los retests ilimitados no son un "plus" del proveedor: son un requisito operativo. Un proveedor que cobra extra por retests añade fricción a un proceso que los auditores ya esperan que ocurra de forma natural y documentada.

El argumento económico: retests como inversión, no como gasto

El costo de un retest como servicio separado oscila entre $2,000 y $10,000 para un alcance limitado, según datos de mercado de 2025. Para una organización que identifica 12 hallazgos y necesita verificar 8 de ellos en múltiples rondas — porque no todos se corrigen correctamente en el primer intento — el costo acumulado puede superar la inversión inicial del pentest completo.

Los proveedores que incluyen retests en el precio base lo pueden hacer porque el costo marginal para ellos es bajo: el pentester ya conoce el sistema, el alcance está definido, y verificar una corrección toma una fracción del tiempo del hallazgo original. El modelo de cobro por retest es una decisión comercial, no una necesidad operativa del proveedor.

El argumento de costo-beneficio es directo: un solo hallazgo crítico que permanece abierto porque el equipo no solicitó retests por costo puede resultar en una brecha. El costo medio de un incidente de datos para organizaciones medianas supera los $3 millones (IBM Cost of a Data Breach Report 2025). Un retest de $3,000 que confirma que el vector de ataque fue efectivamente cerrado es, por definición, una inversión rentable.

Preguntas frecuentes

¿Qué son los retests ilimitados en un servicio de pentesting?

Los retests ilimitados son verificaciones técnicas independientes que confirman si una vulnerabilidad fue realmente corregida. Cuando el pentester identifica un hallazgo, el equipo de desarrollo implementa la corrección, y el retest verifica que el vector de ataque fue efectivamente cerrado — no solo que el síntoma desapareció. Sin retests incluidos, la organización cierra el ciclo de seguridad con suposiciones no verificadas que pueden dejar vectores explotables en producción.

¿Por qué importa que un proveedor ofrezca retests sin costo adicional?

Cuando los retests tienen costo extra, las organizaciones dejan de pedirlos por fricción económica o burocrática. El resultado es que vulnerabilidades documentadas como "en remediación" permanecen abiertas en producción indefinidamente. Según el Ponemon Institute (2024), solo el 34% de las organizaciones verifica activamente que sus remediaciones cerraron las vulnerabilidades identificadas. Los retests sin costo adicional eliminan esa fricción y permiten cerrar el ciclo completo de hallazgo, remediación y verificación.

¿Cuántos retests suele necesitar una empresa después de un pentest?

El número varía según el scope y la velocidad de remediación, pero cada hallazgo de riesgo alto o crítico requiere al menos un retest, y el 15-20% de esos hallazgos necesita un segundo retest porque el fix inicial no cerró el vector completo. Para un pentest típico con 10-15 hallazgos de alta criticidad, esto equivale a entre 10 y 20 verificaciones individuales, cada una con evidencia documentada antes y después de la corrección.

Al evaluar proveedores, el criterio de retests ilimitados es uno de los más fáciles de verificar: basta con leer el contrato. WhiteJaguars, por ejemplo, incluye retests sin restricciones de tiempo ni de número de hallazgos durante toda la vigencia del contrato, con evidencia documentada por remediación. Es un criterio concreto a exigir en cualquier RFP antes de firmar.

Retests ilimitados: por qué deberían ser el estándar en tu pentest