Qué es el retest y por qué prueba que la conducta cambió

La conclusión: el retest es volver a probar la misma categoría de ataque semanas después, con otra plantilla, para ver si la persona aprendió la lección y no el correo

El retest es la segunda prueba de comportamiento que recibe un empleado después de haber fallado en una simulación: semanas más tarde se le envía otro ataque simulado de la misma categoría y dificultad, pero con una plantilla, un remitente y un contexto distintos. Su propósito es único y muy concreto: separar a quien entendió el mecanismo del engaño de quien solo memorizó el correo en el que cayó.

Todo lo demás que se mide en un programa de concientización describe actividad. El retest describe resultado, porque es la única medición que vuelve a poner a la persona en la situación que ya falló, sin avisarle, y observa qué hace esta vez.

Qué es el retest y de dónde viene la idea

El retest no nació en la industria de la capacitación, nació de una incomodidad metodológica: todo programa de concientización afirma que cambia el comportamiento, pero casi ninguno vuelve a medir el comportamiento después de intervenir. Se mide el fallo, se entrega el remedio y se da por cerrado el ciclo con la constancia de que el remedio fue consumido.

La idea es prestada de cualquier disciplina que evalúa una intervención en serio. Nadie considera curada una condición porque el paciente haya asistido a la consulta; se vuelve a medir. Trasladado a la seguridad de las personas, el retest es simplemente eso: una segunda observación bajo condiciones equivalentes, separada en el tiempo de la primera, que convierte una afirmación en una medición.

Vale la pena recordar por qué el esfuerzo se concentra en el correo. CISA señala que más del 90 por ciento de los ciberataques exitosos comienzan con un correo de phishing, así que el buzón corporativo sigue siendo el terreno donde se juega la mayor parte de la prueba, con los frentes nuevos (voz, mensajes de texto, códigos QR) sumándose a ese terreno, no reemplazándolo.

En qué se diferencia de reenviar la misma simulación

Reenviar el mismo correo mide memoria. El retest mide criterio. La diferencia está en lo que se conserva y lo que se cambia entre la primera prueba y la segunda.

Un retest bien diseñado conserva tres cosas: la categoría del engaño (el instinto que explota, por ejemplo la autoridad de un ejecutivo o la presión de un pretexto financiero), el nivel de dificultad y el hecho de que la persona no sabe que está siendo evaluada. Y cambia todo lo demás: el remitente, el asunto, la historia, el diseño y la plataforma suplantada. Si la persona vuelve a caer, no fue porque no reconociera un correo específico, fue porque el mecanismo que la engañó sigue funcionando en ella.

Cuando se repite la plantilla original, el resultado es previsible y poco informativo. Quien acaba de recibir una capacitación sobre ese correo exacto lo detecta, y el programa registra una mejora que no existe fuera del laboratorio. Ese es el modo más común de producir un número bonito sin haber reducido riesgo. También es la razón por la que conviene variar el estilo entre envíos: un equipo puede aprender a reconocer al simulador en lugar de aprender a reconocer al atacante.

Por qué completar una capacitación no basta como prueba de cambio

Porque completar es un acto, no una conducta. Hay evidencia revisada por pares que lo dice sin rodeos: completar una capacitación no predice por sí solo la reducción de fallos reales (Ho et al., IEEE S&P 2025; Lain et al., IEEE S&P 2022). El módulo puede estar bien hecho, ser breve y llegar en el momento exacto del error, y aun así su finalización no constituye evidencia de que la próxima vez la persona actuará distinto.

Esto no es un argumento contra la capacitación, es una corrección de su rol. La capacitación es la remediación, la acción que se toma después del fallo para darle a la persona una explicación útil de lo que le pasó. La prueba viene después, y es de otra naturaleza. Confundir las dos es la razón de fondo por la que tantos programas de capacitación no cambian nada y aun así reportan cumplimiento perfecto.

El marco 90-5-5 de Cisco, que estima que cerca del 90 por ciento de las brechas involucran un factor humano, explica por qué esta distinción no es un detalle académico. Si la mayor parte del riesgo pasa por la conducta de personas, un programa que solo puede demostrar consumo de contenido no está midiendo lo que dice medir.

Cómo se lee un retest: aprobar, reincidir y el piso de riesgo

Un retest tiene tres lecturas posibles y ninguna de las tres es un simple aprobado o reprobado.

La primera es que la persona no cae. Es la señal buena, pero se lee con prudencia: un acierto puntual puede ser suerte, un día tranquilo o una simulación que llegó en mal momento para el atacante simulado. Por eso el retest tiene sentido como serie, no como examen único.

La segunda es que la persona reincide en la misma categoría. Esa es la señal más valiosa del programa, aunque sea la más incómoda, porque señala un patrón de vulnerabilidad específico y no una torpeza general. Alguien puede resistir sin problema los pretextos de urgencia y ceder siempre ante los de autoridad, y ese perfil se vuelve accionable: dice qué reforzar y en qué escenarios volver a probar.

La tercera lectura es la del puntaje de riesgo en el tiempo. La práctica sensata es que un fallo deje a la persona en un nivel de riesgo elevado que no baja por haber aprobado el módulo ni por superar una sola simulación posterior, sino por acumular varias pruebas consecutivas sin caer. Ese piso evita el efecto que arruina la mayoría de los tableros: el riesgo que se declara resuelto porque alguien hizo click en "entendido".

Si en el tablero conviven la tasa de click, la tasa de reporte y el retest, vale la pena tener claro en qué orden se leen esas tres métricas: ahí el retest es un escalón de una escalera de medición; aquí es el mecanismo completo.

Cada cuánto tiene sentido volver a probar

El intervalo razonable está en torno a las tres semanas después del fallo. La razón es un equilibrio entre dos errores opuestos. Si el retest llega a los dos días, mide memoria fresca y no criterio incorporado. Si llega a los seis meses, ya no está midiendo el efecto de esa capacitación sino el estado general de la persona, mezclado con todo lo que pasó en el medio.

Ese intervalo también respeta cómo funciona la atención de un equipo. Tres semanas es tiempo suficiente para que el correo específico se haya diluido en la memoria y para que el trabajo diario haya vuelto a su ritmo normal, que es justo la condición en la que ocurren los engaños reales. Y para quien no ha fallado, la lógica es distinta: no hay retest que aplicar, hay una cadencia regular de simulaciones que mantiene el músculo, con variación de estilo y de dificultad para que nadie aprenda a reconocer el simulacro en lugar del ataque.

Una advertencia final sobre la interpretación. El retest no produce un certificado, produce una serie temporal. Su valor no está en la foto de un mes sino en la curva de reincidencia de una población durante un año, que es lo que de verdad indica si la gestión de riesgo humano (Human Risk Management, HRM) del programa está reduciendo exposición o solo generando actividad.

En Fensivo el retest es el centro del ciclo: cuando alguien cae en una simulación de phishing recibe en minutos una capacitación específica al ataque que lo engañó, y tres semanas después le llega otra simulación de la misma categoría y dificultad, con distinta plantilla, para validar que aprendió la lección y no el correo. El fallo lo deja además en un nivel de riesgo elevado que solo se levanta tras varias pruebas consecutivas sin caer. Puede ver cómo se aplica en nuestros casos de uso.

La pregunta que dejamos abierta es incómoda a propósito: si mañana un empleado suyo aprueba el módulo después de caer en un phishing, ¿con qué evidencia le diría a su directorio que no volverá a caer?