Simulacro de respuesta a incidentes para empleados.
Casi toda la formación en seguridad enseña a no equivocarse. Esta enseña lo otro: qué hacer en los sesenta minutos siguientes al error, que es donde se decide si aquello queda en un susto o acaba en una reclamación.
Un único archivo HTML. Sin instalación, sin servidor y sin recoger ningún dato.
▶ Pruébalo aquí: mr7security.github.io/primera-hora
El error más caro de un incidente casi nunca es el clic. Es la hora que se pierde después, mientras la persona que se ha equivocado intenta arreglarlo por su cuenta, busca en internet, se lo cuenta a un compañero o simplemente espera a ver si pasa algo. Cuando finalmente avisa, ya ha pasado todo lo que tenía que pasar.
Eso no se corrige con más avisos sobre no pulsar enlaces. Se corrige practicando la reacción, y sobre todo quitando el miedo a avisar: quien avisa pronto no es quien la ha liado, es quien ha evitado que fuera a peor. Si esa idea no está clara en una organización, ninguna formación de prevención va a compensar la hora de silencio.
Cada incidente es una línea temporal de sesenta minutos con dos columnas.
A la izquierda, lo que haces tú. Cada acción cuesta minutos: llamar al banco cinco, buscar en internet nueve, esperar a ver qué pasa veintidós. A la derecha, lo que ocurre mientras tanto: los sucesos se disparan al cruzar su minuto, hagas lo que hagas.
La regla que lo sostiene todo: un suceso solo se evita si la acción que lo bloquea se completó antes de ese minuto. Avisar a soporte en el minuto 3 impide que creen una regla de reenvío en el minuto 16. Avisar en el minuto 40 ya no impide nada, aunque sea exactamente la misma acción correcta. No basta con acertar; hay que acertar pronto.
El reloj avanza en minutos simulados, no en tiempo real. Así el coste lo determina la decisión y no la velocidad de lectura, y quien necesita más tiempo para leer no queda penalizado.
Se juegan tres de cuatro por partida.
| Incidente | Lo que enseña |
|---|---|
| He metido la contraseña | Avisar corta más que arreglarlo tú: soporte puede cerrar sesiones y revisar el buzón, tú no. Apagar el ordenador no sirve de nada cuando lo que tienen son tus credenciales. |
| El correo al destinatario equivocado | «Recuperar mensaje» no existe fuera de tu organización, y el plazo de 72 horas para notificar una brecha empieza cuando la empresa tiene conocimiento, no cuando decides contarlo. |
| El portátil en el tren | El aparato cuesta ochocientos euros y se sustituye; la documentación de tres clientes, no. Por eso la primera llamada es a soporte y no a objetos perdidos. |
| La factura que ya he pagado | Solo una acción recupera dinero, y su ventana se mide en minutos. Denunciar, avisar y documentar son imprescindibles, pero van después. |
Cada incidente incluye acciones que empeoran la situación —apagar el equipo, borrar el correo de enviados, esperar a estar seguro— porque son las que la gente toma de verdad y hay que poder equivocarse para entender por qué.
Las acciones están etiquetadas según la fase de respuesta que cubren, siguiendo el ciclo clásico de gestión de incidentes (NIST SP 800-61, adaptado al lenguaje de alguien que no trabaja en seguridad):
- Contener — cortar el problema: cambiar credenciales, bloquear el equipo, parar el pago.
- Comunicar — avisar a quien sí puede actuar: soporte, tu responsable, protección de datos.
- Documentar — dejar por escrito qué pasó, cuándo y a quién afecta.
- Recuperar — volver a la normalidad mientras la ventana sigue abierta.
El informe final muestra cuáles cubriste. La que más se olvida es documentar, y es la que después hace falta para todo.
Consecuencias evitadas frente a consumadas, minutos medios hasta el aviso, decisiones perjudiciales, cobertura de fases y un plan de mejora redactado a partir de lo que hiciste. Imprimible a PDF; no se envía a ninguna parte.
Abre index.html en cualquier navegador. Funciona sin conexión y desde una carpeta compartida.
| Parámetro | Efecto |
|---|---|
?seed=loquesea |
Sorteo reproducible: todos los participantes reciben los mismos incidentes. |
?all=1 |
Juega los cuatro incidentes. |
Duración: unos 20 minutos.
Proyectado en grupo funciona especialmente bien: se lee el disparador en voz alta, se vota qué hacer primero y se ve avanzar el reloj. La discusión sobre si llamar al banco o confirmar primero con el proveedor vale por sí sola toda la sesión.
const CONFIG = {
empresa: "Tu empresa",
logoUrl: "", // ruta a un PNG/SVG; vacío = logotipo generado
color: "#9a3412",
colorOsc: "#7c2d12",
contacto: "la extensión 300", // canal real para avisar de incidentes
asunto: "Aviso de incidente"
};Pon en contacto el canal de verdad. Una formación que enseña a avisar rápido y no dice exactamente a dónde está a medio hacer. Si es una dirección de correo, se convierte en un enlace mailto: con el asunto ya puesto.
- No hay backend. El archivo no realiza ninguna petición de red y la CI lo comprueba en cada cambio.
- No se almacena nada. Ni cookies, ni
localStorage, nisessionStorage. - Nadie ve los resultados. El único informe es el que ve el participante en su pantalla.
En este simulacro concreto importa más que en ningún otro: si alguien sospecha que se está midiendo cómo reacciona ante un error, responderá lo que queda bien en lugar de lo que haría, y el ejercicio deja de servir.
tools/validate.mjs comprueba en cada push las invariantes propias de una línea temporal:
- Que cada consecuencia se pueda evitar, y que se pueda evitar a tiempo: si un suceso ocurre en el minuto 6 y la acción más rápida que lo bloquea cuesta 8 minutos, es imposible de evitar y el ejercicio sería injusto. Es la comprobación más útil de todo el validador.
- Que cada incidente tenga exactamente una acción clave, y que esa acción evite algo de verdad.
- Que haya al menos una acción perjudicial disponible: sin poder equivocarse no se aprende.
- Que ningún suceso ocurra después del límite y que las fases declaradas existan.
- Las promesas del proyecto: sin red, sin almacenamiento, sin recursos externos, más accesibilidad y bloque
CONFIG.
node tools/validate.mjsSi editas el contenido, no borres los marcadores @DATA:START / @DATA:END.
Navegación por teclado, regiones aria-live en la línea temporal, barra de daño anunciada como progressbar, enlace de salto al contenido, prefers-reduced-motion y soporte de forced-colors. En pantallas estrechas la línea temporal de dos columnas se reordena en una sola manteniendo el orden cronológico.
Material exclusivamente educativo. Las empresas, personas y situaciones son ficticias.
- Phantom Desk — phishing, ingeniería social y fraude del CEO.
- Portapapeles — uso seguro de la inteligencia artificial en el trabajo.
Los tres comparten enfoque: decidir y ver la consecuencia, en lugar de leer y responder un test.
MIT.