Cómo introducir simulaciones de phishing sin castigar

La conclusión: una simulación que humilla enseña a esconder el fallo, no a reportarlo

Al introducir simulaciones de phishing en una empresa, la decisión que más pesa no es qué plantilla enviar, sino con qué cultura se envía. Una simulación planteada como una trampa para atrapar al distraído le enseña al equipo a esconder el fallo y a desconfiar del área de seguridad. Una simulación planteada como una práctica sin castigo, anunciada antes de empezar, le enseña a reportar. El objetivo no es cazar a quien cae, es construir un lugar donde avisar de un correo sospechoso sea lo normal y lo seguro.

El primer paso parece contradictorio y no lo es: se anuncia el programa antes del primer envío. No se avisa qué correo llegará ni cuándo, pero sí que la empresa va a practicar con simulaciones, por qué lo hace y qué pasa si alguien cae, que es nada malo. A partir de ahí, introducir la práctica sin romper la confianza es un proceso de cuatro pasos:

Comunicar el programa antes del primer envío, con reglas claras y sin sorpresas punitivas.

Definir qué hacer, y qué no, cuando alguien cae, para que el fallo no se viva como una humillación.

Convertir el fallo en un microaprendizaje inmediato y específico, no en un reporte al jefe.

Validar el cambio con un retest semanas después, no con otro susto.

Los cuatro pasos comparten una misma idea: la persona es el objetivo del ataque, no la causa del ataque, y el programa se diseña para fortalecerla, no para exponerla.

Por qué el enfoque de atrapar al empleado sale caro

Conviene empezar por lo que está en juego, porque explica por qué el tono importa tanto. El marco 90-5-5 de Cisco, que estima que cerca del 90 por ciento de las brechas involucran un factor humano, deja algo claro: la persona es la superficie donde se decide la mayoría de los incidentes. La lectura equivocada de ese dato es tratar a esa persona como un sospechoso al que hay que vigilar. La lectura correcta es que ahí, en el juicio de la gente bajo presión, es donde más se puede reducir el riesgo, y eso se logra fortaleciendo, no castigando.

Cuando una simulación se diseña para atrapar, produce lo contrario de lo que busca. Quien cae y siente vergüenza aprende dos cosas, y ninguna es la que queremos: aprende a ocultar el desliz y aprende a desconfiar de los correos internos de seguridad, justo el canal por el que debería llegar un reporte. Un equipo que esconde los fallos deja ciega al área de seguridad, que se entera de los problemas cuando ya son incidentes. Aquí es donde entra la idea de un programa de comportamiento y cultura de seguridad: el trabajo no es atrapar personas, es cambiar cómo reacciona la organización entera ante un correo sospechoso. Nadie reporta un desliz del que espera ser castigado.

Paso 1: comunicar el programa antes del primer envío

El error más común al arrancar es el silencio: mandar la primera simulación sin avisar, para ver quién cae de verdad. Ese estreno por sorpresa define la relación entera con el programa, y la define mal. Antes del primer envío, conviene comunicar cuatro cosas al equipo, sin revelar las plantillas ni las fechas.

Primero, qué va a pasar: la empresa enviará correos de práctica que imitan ataques reales, de forma periódica. Segundo, por qué: no para evaluar a nadie, sino para entrenar un reflejo que hoy los atacantes explotan a diario. Tercero, qué ocurre si alguien cae: recibe una lección corta en el momento y sigue su día, sin sanción, sin lista pública, sin correo al jefe. Cuarto, qué se espera del equipo: que reporte los correos que le parezcan sospechosos, sean simulación o no, con un botón o una dirección clara. Cuando la gente entiende que reportar es lo que se reconoce y caer no es lo que se castiga, la práctica arranca con la confianza a favor.

Paso 2: definir qué hacer, y qué no, cuando alguien cae

Las simulaciones se hacen sobre el correo porque el correo sigue siendo la principal puerta de entrada: más del 90 por ciento de los ciberataques exitosos comienzan con un correo de phishing, según CISA. Practicar sobre ese vector tiene todo el sentido. Lo que decide si la práctica construye o destruye confianza es lo que ocurre en el minuto siguiente a que alguien hace click.

Qué hacer: mostrar de inmediato, en la misma pantalla, que era una simulación y qué señales la delataban, en un tono que informa y no que regaña. Registrar el evento para el puntaje de riesgo de forma interna, sin exponer a la persona frente a sus compañeros. Tratar el fallo como lo que es, una oportunidad de aprender sobre un ataque que tarde o temprano iba a llegar de verdad.

Qué no hacer: nada de listas públicas de quienes cayeron, nada de correos con tono de reprimenda, nada de avisar al jefe como primera reacción, nada de comparar a unas personas con otras. El momento del fallo es el más frágil de todo el programa. Si ahí la persona siente que la expusieron, no vuelve a confiar, y todo lo demás se derrumba.

Paso 3: convertir el fallo en un microaprendizaje inmediato y sin castigo

El fallo solo enseña si la lección llega enseguida y es específica. Un video genérico sobre qué es el phishing, enviado tres semanas después, no cambia nada: para entonces la persona ya olvidó el correo en el que cayó. Lo que funciona es un microaprendizaje breve, de un par de minutos, que aparece en el momento del click y habla del ataque exacto que la engañó: qué pretexto usó, qué señales tenía y cómo reconocerlo la próxima vez.

Ese enfoque no es un capricho de formato, ataca la razón real por la que la capacitación tradicional no cambia la conducta. La mayoría de la gente le dedica al material de capacitación un minuto o menos, así que una lección larga y a destiempo se ignora. Una lección corta, inmediata y atada a un fallo concreto se recuerda. Y, punto clave para la confianza, el microaprendizaje no es un castigo: es la ayuda que la persona recibe para no volver a caer. Si el programa escala algo al jefe, debería dispararse porque alguien no completó su lección, no por el hecho de haber caído. Se destraba una tarea pendiente, no se señala a un culpable.

Paso 4: validar el cambio con un retest, no con otro susto

El último paso es el que casi nadie da, y es el que prueba que el programa sirve. Completar la lección no demuestra que la conducta cambió. Hay evidencia revisada por pares de que haber completado 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): la gente aprueba el módulo y vuelve a caer. Lo que demuestra el cambio es volver a probar el comportamiento.

A eso se le llama retest: semanas después del fallo, la persona recibe una simulación de la misma categoría y dificultad, pero con otra plantilla y otro contexto. Si esta vez no cae, hay evidencia real de que aprendió la lección y no solo memorizó aquel correo. Si vuelve a caer, el programa lo sabe y ajusta, sin dramatizarlo. Visto así, el retest no es otro susto ni una segunda trampa: es la forma honesta de saber si la práctica funcionó, y encaja con la cultura de reporte porque mide a la organización, no señala a la persona.

Un programa de gestión de riesgo humano (Human Risk Management, HRM) construido con este criterio automatiza lo que más pesa de este enfoque: entrega el microaprendizaje específico en minutos cuando alguien cae, sin sanción, y semanas después envía un retest de la misma categoría con otra plantilla para validar que la lección quedó. Así diseñamos Fensivo, que trata cada fallo como un punto de aprendizaje y no como una falta, para que introducir simulaciones fortalezca la confianza del equipo en vez de erosionarla. Para ver cómo se aplica a un caso concreto, están nuestros casos de uso.

¿La próxima simulación de phishing va a servir para señalar a quién cayó, o para construir un equipo que reporta sin miedo?

Fuentes y referencias

• CISA, Shields Up: Guidance for Families: https://www.cisa.gov/shields-guidance-families
• Cisco, The 90-5-5 Concept: Your Key to Solving Human Risk in Cybersecurity (2025): https://blogs.cisco.com/security/the-90-5-5-concept-your-key-to-solving-human-risk-in-cybersecurity
• Ho et al., Understanding the Efficacy of Phishing Training in Practice, IEEE Symposium on Security and Privacy 2025: https://ieeexplore.ieee.org/document/11023357/
• Lain et al., Phishing in Organizations: Findings from a Large-Scale and Long-Term Study, IEEE Symposium on Security and Privacy 2022: https://ieeexplore.ieee.org/document/9833766/