Cuando en una organización pasa algo, la historia circula igual, es un hecho. Alguien cuenta por chat lo poco que sabe, otra persona agrega lo que se imagina, y a los pocos días la historia que circula no se parece a la que pasó. Mientras tanto, la versión que explica cómo funcionó el engaño paso por paso no aparece por ningún lado. Y es la única que serviría para que no vuelva a pasar. ¿Por qué se queda guardada? Porque contarla completa parece obligarnos a decir quién fue, y ahí el relato se frena. Es una lástima, porque ese incidente propio es el material de concientización con más fuerza que tiene una organización, y ya está pagado.
¿Por qué el incidente propio enseña más que el ejemplo de manual?
Porque un ejemplo de manual describe un engaño que funcionó en otro lado, y el incidente propio describe uno que funcionó aquí. Para quien escucha son dos cosas muy distintas. Con el ejemplo de afuera tenemos que imaginar por nuestra cuenta cómo sería ese correo en nuestro puesto, con nuestros sistemas y con la gente que nos escribe todos los días. Cuando el relato viene de adentro no hace falta imaginar nada, porque aparecen los nombres de las herramientas que usamos, el tipo de pedido que circula por aquí y el momento en que un pedido así no llama la atención.
Y hay algo más que ningún contenido comprado puede aportar. El incidente propio demuestra que aquí pasa. Mientras el riesgo se explica con casos ajenos, las personas tendemos a escucharlo como se escucha una noticia, con interés y con la sensación de que eso les pasa a otros. Un caso propio acorta esa distancia mejor que cualquier estadística.
Ahora bien, esa misma fuerza lo vuelve delicado. El relato que más enseña es también el que más fácil deja expuesta a una persona, así que antes de contarlo hay que decidir cómo se cuenta.
Qué hay que sacar del relato antes de contarlo
El nombre es lo primero que sale y es lo más fácil. Lo difícil viene después, porque en un relato detallado hay bastantes datos que reconstruyen a la persona sin nombrarla: el área cuando es pequeña, el día y la hora, el cliente que aparecía en el correo, el importe, la versión del sistema que usa un solo equipo. Con esos datos cruzados, quienes trabajan con esa persona saben de quién hablamos.
Aquí entra en juego un criterio simple, y es contar el mecanismo completo y el contexto mínimo. Del mecanismo no sacamos nada, ya que ahí está todo lo que se aprende. ¿Y cuánto es el contexto mínimo? El que haga falta para entender el engaño, ni un dato más. Supongamos que el borrador está listo y que lo lee el equipo de la persona involucrada. Si desde ahí pueden señalarla, todavía nos falta trabajo.
Lo que se queda en el relato describe el ataque, y nada de eso apunta a una persona:
- El pedido y el canal por donde llegó. Qué pedía el mensaje, con qué urgencia y por dónde entró, para reconocer el mismo intento la próxima vez.
- La señal que estaba a la vista. El detalle que no cerraba, contado sin ironía, porque se ve fácil una vez que sabemos el final.
- Cómo se detectó y qué lo frenó. El aviso, la llamada de verificación o el control que saltó, que es la parte que muestra que el sistema hizo su trabajo.
Y queda una cosa más, que no es sobre el texto. A la persona involucrada le avisamos antes, aunque el relato salga sin ningún dato suyo. Enterarse por un boletín interno de que la propia historia se está usando como material hace que, la próxima vez, la historia se guarde.
¿Cuándo se cuenta?
Lo habitual es que esta decisión no esté escrita en ningún lado. El Cyber Security Breaches Survey 2025/2026 del Gobierno del Reino Unido midió que el 57% de las medianas empresas y el 76% de las grandes tienen un plan formal de respuesta a incidentes, así que una de cada cuatro organizaciones grandes no tiene ninguno. Y la encuesta cuenta como plan a quién notificar, quién hace qué y cuándo reportar afuera. Contar el incidente puertas adentro, para que la organización aprenda algo, no entra en esa lista.
No se cuenta mientras se está conteniendo. En esas horas el relato compite con el trabajo de resolverlo, y todavía no sabemos bien qué pasó, así que lo que salga va a ser la primera versión, la que suele corregirse a los pocos días. Tampoco se cuenta tan tarde que la organización lo haya dado por cerrado, porque un relato que llega cuando el tema se enfrió se lee como un trámite.
La ventana que mejor funciona es cuando el incidente está cerrado y todavía nos acordamos de que pasó algo. En ese momento hay una curiosidad que después se apaga, y esa curiosidad es atención que no tuvimos que fabricar, la misma que cuesta tanto conseguir el resto del año. Dejarla pasar sale caro, porque la misma historia contada meses más tarde necesita un esfuerzo enorme para que alguien la lea.
El relato tiene una segunda vida, eso sí. Cuando entra gente nueva, el incidente que para nosotros es viejo vuelve a ser información útil. Para esas personas no es historia vieja, y explica mejor que cualquier política por qué aquí pedimos lo que pedimos.
El tono decide si la próxima vez alguien avisa
Esta es la parte cara de hacer mal. Un relato que termina en moraleja se lee como advertencia, y entendemos rápido qué nos espera si algún día nos toca a nosotros. Lo que se rompe ahí es el canal de reporte. La próxima persona a la que le pase algo va a tardar unas horas más en avisar, o va a intentar arreglarlo sola primero, y el tiempo entre el error y el aviso es lo que decide el tamaño del incidente. Un programa puede perder en una sola comunicación mal escrita buena parte de la confianza que tardó años en construir.
Hay una regla simple de aplicar cuando la tenemos presente, y es que el sujeto de las oraciones del relato es el engaño y el sistema. El correo pedía tal cosa, llegaba desde una dirección parecida a la del proveedor y resultaba creíble porque aquí los pedidos de ese tipo llegan así. Todo eso describe el ataque con precisión y deja la decisión de una persona fuera del relato. Tampoco hace falta agregar la aclaración de que la culpa no fue de nadie, ya que nombrar la culpa la instala.
Y hay una parte del relato que pesa más de lo que parece, que es el final. Si la historia termina en cómo se detectó, con el nombre del control o del canal que la frenó, nos queda instalado el reflejo de avisar, y ese es exactamente el comportamiento que buscamos para la próxima vez.
Qué hacer cuando el incidente no se puede contar
A veces no se puede y las razones son buenas. Hay un cliente involucrado, una investigación abierta, una obligación de notificación con plazos propios o un contrato que define qué se puede decir. Cuando pasa eso, esperar a que se pueda suele equivaler a no contarlo nunca. ¿Se pierde entonces la enseñanza? No toda, porque nos queda la versión desplazada, que cuenta el mecanismo sin el caso.
En lugar de “nos pasó esto”, la comunicación avisa que está circulando un pedido de este tipo, con estas características, y explica cómo verificarlo antes de responder. Pierde la prueba de que aquí pasa, que era lo más valioso, y gana algo que compensa bastante, porque se puede publicar mientras el mecanismo todavía está activo.
La otra salida dura más, porque en lugar de comunicar convierte el mecanismo en algo que podemos volver a usar.
De anécdota suelta a material que dura
Un relato contado una vez llega hasta donde llegó ese día. Al tiempo hay gente nueva, gente que estaba de licencia y gente que lo leyó por encima, así que para que el incidente siga enseñando hay que sacarlo del formato de comunicado y pasarlo al programa.
La forma más directa es llevar el mecanismo a una simulación propia. En las simulaciones de phishing de SMARTFENSE se pueden editar los contenidos predefinidos o crear uno nuevo desde cero, de manera que el mismo tipo de pedido, con el mismo estilo de remitente y la misma excusa, vuelve a circular semanas después sin que haya nadie expuesto. Para quien realice la acción de riesgo, un Momento Educativo explica en ese instante qué pasó y cómo reconocer el engaño la próxima vez, con una pregunta de validación que confirma que el contenido se leyó. Es la diferencia entre prevenir y corregir aplicada a un caso que conocemos de memoria.
Aquí hay un límite que vale respetar, y es más estricto que el del comunicado. La simulación replica el mecanismo y el caso queda afuera. Si reproduce el incidente con sus detalles reconocibles vuelve a exponer a la persona que lo vivió, esta vez delante de toda la organización y con el sello del programa encima.
El resto de los usos es más tranquilo y no nos pide ninguna decisión difícil. El mecanismo entra en el material de quienes se incorporan, vuelve una vez al año como recordatorio y le da a la política interna el ejemplo que le faltaba.
Qué versión queremos que circule
Volvamos a las versiones del principio. La historia va a circular de todos modos. Lo único que la organización decide es cuál de todas tiene los detalles, explica el mecanismo y llega a todo el mundo, y esa decisión se toma en los días siguientes al incidente o se pierde.
En definitiva, la versión que sirve tiene una forma bastante reconocible. Cuenta cómo funcionó el engaño con precisión, no permite señalar a nadie, termina en cómo se detectó y nos deja con una idea clara de qué hacer si mañana nos llega algo parecido.
Si en tu organización ya pasó algo y todavía nadie lo contó, tal vez este sea un buen momento para escribir esa versión. Porque el incidente ya lo pagamos, y lo que queda por decidir es si además nos enseña algo.
Deja un comentario