La lección anterior terminó señalando un patrón: detrás de cada control, cada evidencia y cada hallazgo hay una persona que hace o no hace algo. Lucía sabía dónde estaba cada cosa; el alta fuera de flujo ocurrió porque alguien tenía prisa un domingo; el runbook falla porque solo una persona sabe lo que no está escrito en él. Ninguna matriz de trazabilidad corrige eso. Esta lección trata el factor que sigue siendo el vector principal de los incidentes y, a la vez, la mejor defensa que existe cuando funciona: las personas. Y lo hace desde una premisa incómoda: el objetivo no es que la gente sepa. El objetivo es que haga, y sobre todo que reporte.

Nota de validación. Este apartado tiene implicaciones laborales y de protección de datos: la obligatoriedad de la formación, el registro de asistencia, el tratamiento de los datos de los simulacros de phishing y las consecuencias disciplinarias varían según el convenio, el contrato y la normativa aplicable, y en muchos casos exigen información previa a la plantilla o consulta a la representación de los trabajadores. Es material formativo, no asesoramiento jurídico: valídalo con asesoría laboral y con el delegado de protección de datos antes de implantarlo (ver 06-03).

1. Por qué esto no es «la charla anual obligatoria»
2. Concienciación, formación y cultura: tres cosas distintas
3. Qué necesita saber y hacer cada rol de Nimbus
4. El programa anual, diseñado para caber en una PYME
5. Acogida y salida: el ciclo de vida de la persona
6. Canales y formatos que funcionan (y los que no)
7. Simulacros de phishing bien hechos
8. El botón de reportar y el circuito de respuesta
9. Cultura justa: por qué culpar destruye la detección
10. Medir el programa: comportamiento frente a vanidad
11. Campeones de seguridad y formación para desarrollo
12. La dirección también se forma

En 02-03 vimos la ingeniería social como técnica de ataque, y la conclusión era demoledora: no explota un fallo técnico, explota la disposición humana a ayudar, a obedecer y a evitar problemas. Los informes del sector coinciden año tras año en que una proporción muy alta de las brechas involucra el elemento humano —error, uso indebido de credenciales, phishing o ingeniería social— y el incidente de 02-06 no fue una excepción: el atacante entró por una credencial de un tercero que nadie revisaba, y en el día 16 una alerta de coste anómalo llegó al correo de Lucía y se marcó como «revisar luego» entre otros doscientos correos.

Frente a eso, la respuesta habitual de las organizaciones es un curso anual de cuatro horas con un test final. Y no funciona, por cuatro razones que conviene tener claras antes de diseñar nada:

• La curva del olvido. Sin refuerzo, la retención de una sesión larga cae drásticamente en pocos días. En el mes 11 del año, la formación de enero es indistinguible de no haberla hecho.
• Saber no es hacer. Todo el mundo sabe que no debe reutilizar contraseñas. La mitad lo hace igualmente. El conocimiento no cambia el comportamiento por sí solo, sobre todo bajo presión.
• El momento equivocado. Se forma en enero y el ataque llega en septiembre, en mitad de un lanzamiento, con prisa, desde el móvil. El aprendizaje descontextualizado no se activa en ese instante.
• Enseña a temer el error en lugar de a reportarlo. El test final con nota, la lista de quién ha aprobado y el tono de «no seas tú el que caiga» producen el efecto contrario al deseado: quien pique lo callará.

El cambio de objetivo que ordena toda la lección. No se trata de que nadie caiga nunca —eso es imposible: un phishing bien hecho engaña a cualquiera en el momento adecuado—, sino de que cuando alguien caiga, se sepa en minutos. Compara los dos escenarios en Nimbus:

La frase que resume la lección y que conviene repetir en cada píldora: el error no es el incidente; el silencio sí.

Se usan como sinónimos y son tres capas con objetivos, formatos y horizontes distintos. Confundirlas explica por qué muchos programas fracasan: se compra formación cuando lo que hacía falta era concienciación, o se espera cultura de un cursillo.

Las tres son necesarias y ninguna sustituye a otra. La concienciación sin formación produce gente asustada que no sabe qué hacer. La formación sin concienciación produce conocimiento que se apaga en tres semanas. Y ambas sin cultura producen personas que saben lo correcto y hacen lo contrario porque el entorno premia la velocidad y castiga la pregunta. La cultura, además, no se enseña: se deduce de lo que la dirección premia, tolera e ignora —volveremos a ello en el apartado 9—.

Un programa dirigido a «todos» acaba siendo genérico y por tanto olvidable. El punto de partida es el análisis de necesidades: para cada perfil, qué riesgos tiene delante y qué debe ser capaz de hacer.

Dos criterios de diseño que evitan el error más común. Primero: el itinerario se define por lo que la persona debe hacer, no por lo que estaría bien que supiera. Rubén no necesita saber qué es un ataque de fuerza bruta; necesita saber que no se cambia un correo de contacto sin verificar por el canal registrado. Segundo: la base común es común de verdad, y corta. Cuatro horas al entrar y una píldora al mes es todo lo que se le pide a alguien cuyo trabajo no es la seguridad, y es suficiente si esas horas están bien invertidas.

El presupuesto y el tiempo son los de siempre: parte de los 18.000 € y horas contadas de cada persona. El programa se diseña con esa restricción desde el principio, no como una aspiración que se recorta después.

Por qué píldoras cortas y frecuentes en lugar de un curso anual de cuatro horas. No es una preferencia estética, es aprendizaje espaciado: la repetición distribuida en el tiempo retiene mucho más que la misma cantidad de contenido concentrada. Y hay tres ventajas prácticas para una PYME: cuesta menos tiempo agregado (10 minutos al mes son 2 horas al año frente a 4 de golpe), permite reaccionar —si aparece una campaña de phishing dirigida al sector, la píldora de ese mes habla de eso— y mantiene el tema vivo, que es literalmente la definición de concienciación.

El momento de mayor riesgo y de mayor oportunidad es la entrada. El nuevo empleado no conoce las normas, no sabe distinguir un correo interno legítimo de uno falso, no conoce las caras ni las voces y está deseando causar buena impresión —la combinación perfecta para la ingeniería social—. Retomando el ciclo de vida de la identidad de 02-05, ahora en su vertiente formativa:

Dos detalles del día 0 que cambian el resultado. El primero: la aceptación de POL-04 se firma antes del primer acceso, no en el segundo mes. Es la base disciplinaria y la evidencia de 06-04, y su fecha debe ser anterior a cualquier uso de los sistemas. El segundo: el MFA y el gestor de contraseñas se instalan con acompañamiento, no con un enlace a un manual. La adopción de una herramienta cae en picado si la primera experiencia es frustrante, y el gestor de contraseñas es la única herramienta de esta lección cuyo uso se puede medir directamente.

La salida tiene una parte formativa que casi nadie hace: la conversación de cierre. Además de la revocación de accesos en 24 horas y la devolución del equipo, conviene recordar por escrito y de forma no amenazante el deber de confidencialidad sobre lo que la persona conoce —clientes, arquitectura, vulnerabilidades— y preguntar qué sabe que no está escrito. Esa última pregunta, hecha a Lucía el día que se fuera, es la única mitigación real de R-09 que no cuesta dinero.

Y el cambio de puesto es el eslabón olvidado. Cuando Rubén pasa de soporte a preventa, lo habitual es añadirle los accesos nuevos y no quitarle los antiguos: es la acumulación de privilegios de 02-05, y se corrige tratando el cambio de puesto como una baja seguida de un alta, con su formación correspondiente.

El aviso contextual es el formato de mejor retorno y el más infrautilizado. Cuesta poco y actúa en el instante que importa: el banner [EXTERNO] en correos de fuera del dominio, la advertencia al adjuntar un fichero con datos personales a un destinatario externo, el recordatorio en el panel cuando alguien va a exportar más de 500 registros, o la confirmación adicional al cambiar una cuenta bancaria de proveedor. Ninguno de estos enseña nada; todos cambian comportamiento, que es lo que se buscaba.

Por qué el material genérico comprado suele fracasar. Un vídeo con actores en una oficina que no se parece a la vuestra, hablando de una amenaza abstracta, produce cumplimiento formal y cero cambio. El vídeo de ocho minutos en el que Marta cuenta el incidente de 02-06 —qué hizo el atacante, qué alerta se ignoró el día 16, qué habría cambiado un MFA— vale por diez cursos comprados, porque es su empresa, sus datos y sus caras. La regla práctica: compra el marco si te ahorra tiempo, pero produce tú los ejemplos, y presupuesta un par de horas al mes para hacerlo.

Es la herramienta más potente del programa y la que más daño hace mal usada.

El objetivo, declarado y comunicado desde el principio: medir y entrenar el reporte, no cazar culpables. Si la plantilla percibe que el simulacro es una trampa para señalar a quien falla, aprenderá exactamente una cosa: a no contar nada. Ese resultado es peor que no hacer simulacros.

Diseño de campaña por dificultad. Se empieza fácil y se sube, para que la gente vea progreso y para que el dato sea interpretable:

La regla ética, que no se negocia. No se usan señuelos que exploten la vulnerabilidad personal ni la ansiedad legítima. Quedan prohibidos: nóminas, bonus, despidos o ERE, ayudas sociales, resultados médicos, temas familiares, emergencias reales y cualquier suplantación de un compañero identificable por su nombre. La razón no es solo ética: un señuelo cruel funciona siempre —así que no mide nada— y produce un daño de confianza que tarda años en repararse. Un simulacro que anuncia una subida salarial inexistente puede tener un 80 % de clic y haber destruido el programa entero.

Qué se hace con quien pica. Formación inmediata y breve en el momento: al hacer clic, una página que explica en 60 segundos cuáles eran las señales concretas de ese correo y cómo reportar la próxima vez. Nada más. Nunca una lista pública, nunca un correo a su responsable, nunca una anotación en su evaluación de desempeño. Y si alguien pica repetidamente, la conversación es individual, privada y de ayuda: casi siempre revela un problema de contexto —trabaja bajo presión, recibe cientos de correos externos legítimos, tiene un puesto que exige abrir adjuntos de desconocidos— que se resuelve con una medida técnica, no con un reproche.

Nota de validación. Los simulacros tratan datos personales de la plantilla (quién hizo clic, cuándo, desde qué dispositivo) y tienen implicaciones laborales. Requieren base jurídica, información previa clara sobre que se realizarán simulacros y con qué finalidad, minimización —trabajar con datos agregados siempre que sea posible—, plazo de conservación corto y, con frecuencia, información a la representación de los trabajadores. Consúltalo con el DPD y con asesoría laboral (06-03).

Las métricas correctas. Aquí está el error más extendido del sector: mirar solo la tasa de clic. Tres campañas de Nimbus:

Cómo se lee esta tabla, que es lo que separa un programa útil de un teatro. Una lectura ingenua diría que el programa empeoró: la tasa de clic subió del 21 % al 31 % en la última campaña. La lectura correcta es la contraria, y por tres motivos. Primero, la dificultad subió: la tercera campaña era un señuelo dirigido y creíble, y comparar su tasa de clic con la de un señuelo burdo no tiene sentido. Segundo, la tasa de reporte se multiplicó por más de cuatro, del 15,8 % al 69,2 %: ahora dos de cada tres personas avisan. Tercero, y es el dato decisivo, el tiempo hasta el primer reporte cayó de 47 minutos a 4. Eso significa que en un ataque real Lucía tendría aviso antes de que el atacante terminara de autenticarse, y podría revocar la sesión y forzar el cambio de credencial mientras el ataque aún está en curso. Y las credenciales introducidas —el único dato que mide daño real— cayeron de 4 a 0.

La conclusión, que conviene tener escrita antes de la primera campaña: la tasa de clic mide la dificultad del señuelo; la tasa de reporte y el tiempo al primer reporte miden la salud del programa. Si solo puedes seguir un número, sigue el tiempo al primer reporte.

Todo lo anterior se apoya en un mecanismo que tiene que ser trivial. Si reportar cuesta más de dos segundos o genera dudas sobre si molesta, no se usará.

Requisitos del canal de reporte, en orden de importancia:

1. Un solo gesto: un botón en el cliente de correo, que reenvía con cabeceras completas y archiva el mensaje. Nada de «reenvíalo a seguridad@ con el asunto en este formato».
2. Disponible donde ocurre el riesgo: en el correo, en el móvil y también para lo que no es correo —una llamada rara, un USB encontrado, una web sospechosa— con un canal alternativo igual de simple.
3. Respuesta siempre y en el día, aunque sea falsa alarma. El reporte sin respuesta es un reporte que no se repetirá.
4. Agradecimiento explícito, sin excepción. Incluido cuando era claramente publicidad legítima.
5. Sin fricción emocional: nada de formularios que pregunten «¿ha hecho usted clic?» en tono de interrogatorio. Si ha hecho clic, esa información es la más valiosa de todas y hay que hacer que sea fácil darla.

Dos consecuencias de este circuito que suelen sorprender. La primera: los falsos positivos son buena señal, no una molestia. Alguien que reporta un boletín legítimo está usando el mecanismo, y la respuesta correcta es agradecerlo. Una organización sin falsos positivos no tiene un canal afinado: tiene un canal que nadie usa. La segunda: el volumen de reportes es un indicador de confianza, no de amenaza. Si los reportes caen a la mitad, la hipótesis más probable no es que haya menos phishing.

La cultura justa (just culture) distingue entre error humano —que se consuela y se corrige con diseño—, conducta arriesgada —que se coacha— y conducta temeraria o dolosa —que sí tiene consecuencias—. La distinción importa porque el 95 % de lo que ocurre en seguridad es lo primero.

El razonamiento económico de la cultura justa, para quien necesite un argumento que no sea moral. Castigar al que pica reduce marginalmente la tasa de clic —la gente se vuelve algo más cauta— pero reduce drásticamente la tasa de reporte, porque el coste personal de admitir el error se dispara. Y como el daño de un incidente crece con el tiempo de exposición —los 20 días de 02-06—, el balance es claramente negativo: se cambian unos pocos clics evitados por un aumento enorme del tiempo de detección. Culpar al que pica es, literalmente, comprar ceguera a cambio de nada.

Esto conecta directamente con el post mortem sin culpables de 04-05: la misma lógica que allí se aplicaba a los incidentes técnicos —preguntar qué del sistema permitió el fallo, no quién lo cometió— se aplica aquí a los errores cotidianos. Y con la señal de cultura de 06-01: se reportan los errores propios sin miedo. Si eso no ocurre, ningún programa de formación lo va a arreglar, porque el problema no está en lo que la gente sabe.

Los de la izquierda no son inútiles: son evidencia de cumplimiento para 06-04 y para el artículo 32.4 del RGPD, y hay que llevarlos. Pero no dicen nada sobre si el programa funciona. Los de la derecha sí, y tres merecen comentario:

• Nº de consultas preventivas. Es el indicador más ignorado y probablemente el mejor. Cuando alguien pregunta «¿puedo mandar este export por correo?» antes de hacerlo, el programa ha ganado. Se cuenta trivialmente en el buzón de seguridad, y su crecimiento es la señal más temprana de que la cultura está cambiando.
• Incidentes por error humano. Debe leerse con cuidado: al principio del programa sube, porque se reportan más. Esa subida es buena. Lo que hay que mirar es la gravedad media y el tiempo de detección.
• Uso del gestor de contraseñas. Es el único comportamiento de esta lección que se mide de forma objetiva y continua, sin encuestas ni simulacros.

Presentado como cuadro de mando del programa, alimentando el de 06-01:

Campeones de seguridad (security champions). Es la forma más barata de escalar sin contratar: una persona de cada equipo que dedica un porcentaje pequeño de su tiempo a ser el punto de contacto de seguridad de su área. En Nimbus, con 38 personas, bastan dos: Iván en desarrollo y una persona de soporte o administración.

Qué hace un campeón: es el primero al que se pregunta, revisa los PR marcados como sensibles, lleva las novedades de seguridad a su equipo en su lenguaje y traslada hacia arriba la fricción real —qué control está estorbando y por qué la gente lo esquiva—, que es información que Marta no obtendría de otra forma. Qué no es: ni el responsable de seguridad del equipo, ni el que arregla todo, ni un puesto sin tiempo asignado. Necesita horas explícitas (2-4 h al mes), formación adicional y reconocimiento visible.

Formación para desarrollo con código propio. Aquí está la diferencia entre un taller que se recuerda y uno que se olvida. Compara:

El ejercicio de la última fila es el más valioso de todo el programa técnico y cuesta media hora: cada desarrollador rompe deliberadamente un control —quita el filtro de tenant, sube un secreto, añade una dependencia vulnerable— y comprueba que semgrep, gitleaks y pip-audit le paran. Aprende dos cosas a la vez: cómo son los fallos reales y que la red de seguridad existe y funciona. Y de paso genera evidencia de que el CI de AppSec de 05-05 hace lo que dice.

Es el hueco más común: se forma a toda la plantilla y se asume que la dirección ya sabe. Pero Marta no necesita saber qué es un IDOR; necesita decidir bien con información incompleta, y eso también se entrena.

Qué necesita Marta:

• Leer un registro de riesgos y decidir: entender ALE, riesgo residual y apetito lo suficiente para elegir entre mitigar, transferir, evitar y aceptar, y para saber que aceptar es una opción legítima si se documenta.
• El marco legal que la afecta personalmente: la responsabilidad de la dirección en NIS2, las obligaciones del RGPD, el plazo de 72 horas y la exigencia de formación para los órganos de dirección.
• Presidir una crisis: el tabletop semestral no es para el equipo técnico, es sobre todo para ella. Decidir con información incompleta, autorizar una parada de servicio, hablar con clientes.
• Reconocer cuándo le están vendiendo humo: saber preguntar «¿cuándo se probó esto por última vez y dónde está el informe?» ante cualquier proveedor o cualquier informe interno.
• Ejemplaridad: si Marta pide una excepción al MFA «porque tiene prisa», el programa entero pierde credibilidad en un día. La dirección que se salta sus propios controles enseña más que doce píldoras.

Cómo se le presenta el riesgo para que decida bien. No con CVSS ni con nombres de vulnerabilidades, sino en términos de negocio y con una decisión concreta encima de la mesa:

La regla: cada informe a dirección termina en una decisión pedida, con su coste, su plazo y su consecuencia de no hacer nada. Un informe sin decisión pedida es información; con ella, es gestión.

• Medir la tasa de clic como indicador principal. Mide la dificultad del señuelo, no la salud del programa. Mira la tasa de reporte y, sobre todo, el tiempo al primer reporte.
• Usar señuelos crueles. Nóminas, despidos, ayudas o resultados médicos funcionan siempre —y por eso no miden nada— y destruyen la confianza que sostiene todo el programa.
• Publicar quién ha picado. Garantiza que el próximo error se calle. Formación inmediata, privada y breve; nunca lista pública.
• Comprar un catálogo genérico y llamarlo programa. El vídeo con actores en una oficina ajena produce cumplimiento formal y cero cambio. Compra el marco, produce tú los ejemplos.
• Un curso anual de cuatro horas. La curva del olvido lo desactiva en semanas. Píldoras cortas y frecuentes retienen mucho más con el mismo tiempo total.
• Nombrar campeones de seguridad sin horas asignadas. Es un título sin efecto y una frustración garantizada. Sin 2-4 h al mes explícitas, no existe.
• No formar a la dirección. Es quien más decisiones toma y quien más responsabilidad legal asume desde NIS2. Y quien más daño hace al programa si se salta sus propios controles.
• Consejo: si solo puedes hacer una cosa, pon el botón de reportar y responde a cada reporte el mismo día con un gracias. Cuesta una tarde de configuración y 10 minutos diarios, y es la mejor reducción de dwell time por euro que existe.
• Consejo: usa tus propios incidentes. El caso de Nimbus contado por Marta en ocho minutos vale más que cualquier material comprado. Anonimiza al protagonista, nunca el aprendizaje.
• Consejo: mide el uso del gestor de contraseñas. Es el único comportamiento que se puede observar de forma continua y objetiva, sin encuestas y sin simulacros.

Ejercicio 1 — Rediseñar un simulacro mal planteado

Sara propone la siguiente campaña: un correo aparentemente de la gestoría con asunto «Revisión de tu nómina: variación en el IRPF de enero» y un enlace a un portal falso que pide usuario y contraseña corporativos. Plantea publicar en el canal general la lista de quienes hayan introducido credenciales «para que sirva de escarmiento», y medir el éxito por la reducción de la tasa de clic respecto a la campaña anterior.

Identifica cuatro problemas —éticos, jurídicos y de diseño—, y rediseña la campaña completa: señuelo, comunicación previa, qué ocurre al hacer clic, qué se publica y qué métricas se usan.

Ejercicio 2 — El programa de una persona nueva

Nimbus contrata a una desarrolladora que se incorpora en dos semanas y trabajará en remoto desde otra ciudad. Diseña su plan de los primeros 30 días desde el punto de vista de seguridad: qué ocurre antes del primer acceso, qué en la primera semana, qué en el primer mes; quién hace cada cosa; qué evidencia queda; y qué se hace distinto por ser remota y por ser de desarrollo.

Ejercicio 3 — Leer los datos de tres campañas

Marta mira la tabla del apartado 7 y dice: «En 2027-Q1 hemos empeorado: la tasa de clic ha subido del 21 % al 31 %. Propongo hacer el curso obligatorio otra vez y avisar de que el próximo que pique tendrá una conversación con su responsable.»

Responde a Marta con un análisis correcto de los datos, explica por qué su propuesta empeoraría los resultados y propón tres acciones concretas para el trimestre siguiente, con su coste y el indicador que cada una debería mover.

Ejercicio 1

Cuatro problemas:

1. Señuelo prohibido por la regla ética. La nómina y el IRPF tocan la seguridad económica personal. Un señuelo así funciona casi siempre, con lo que no discrimina entre quien está atento y quien no: no mide nada. Y produce un daño de confianza desproporcionado —la gente siente que su empresa ha usado su sueldo como cebo—.
2. Publicar la lista es inaceptable en varios planos a la vez. Éticamente es humillación pública. Jurídicamente es un tratamiento de datos personales sin base adecuada y con altísimo riesgo de daño reputacional interno, además de tener implicaciones laborales evidentes. Y operativamente es contraproducente: garantiza que el próximo error real se oculte, que es exactamente lo contrario del objetivo.
3. La métrica es errónea. La tasa de clic depende de la dificultad del señuelo y no dice nada sobre la capacidad de respuesta. Faltan la tasa de reporte y el tiempo al primer reporte, que son las que se correlacionan con daño evitado.
4. Falta la comunicación previa y la base para tratar los datos. No consta que la plantilla haya sido informada de que se realizan simulacros, ni con qué finalidad, ni qué datos se recogen ni cuánto se conservan; ni consta consulta a la representación de los trabajadores donde proceda.

Campaña rediseñada:

• Antes (una sola vez, al inicio del programa). Comunicación a toda la plantilla: se realizarán simulacros periódicos, su finalidad es medir y mejorar la capacidad colectiva de detección, los resultados individuales no se comunican a los responsables ni se usan en la evaluación del desempeño, los datos se tratan de forma agregada y se conservan un plazo corto y declarado. Validado con el DPD y con asesoría laboral, con la información previa que corresponda.
• Señuelo (nivel 2, contextual). Suplantación de un proveedor real de la empresa —por ejemplo, una notificación de la plataforma de facturación pidiendo revisar un documento—. Es verosímil, es plausible en el contexto laboral, discrimina bien entre atención y descuido, y no toca nada personal.
• Al hacer clic. Página inmediata de 60 segundos: «Esto era un simulacro de Nimbus. Estas eran las tres señales: el dominio era facturacion-portal.example y no el habitual, el saludo era genérico y el enlace no coincidía con el texto. No pasa nada por haber hecho clic: lo importante es reportar. Así se hace, en dos segundos: [botón]». Ningún registro visible para el usuario, ninguna nota, ninguna comunicación a nadie.
• Si alguien introduce credenciales. La página lo indica con claridad y añade una instrucción accionable: cambia la contraseña ahora y comprueba tu MFA. Y una nota interna para Lucía: si esto ocurriera de verdad, este es el número de personas cuya sesión habría que revocar, que es el dato que alimenta el runbook.
• Qué se publica. Solo resultados agregados, en el canal general y en tono de equipo: «69 % de reportes, primer aviso en 4 minutos, cero credenciales. Gracias a los 27 que reportasteis.» Se reconoce públicamente a quien reporta primero, nunca a quien pica.
• Métricas. Tasa de reporte, tiempo al primer reporte, credenciales introducidas y evolución respecto a campañas del mismo nivel de dificultad. La tasa de clic se registra pero se lee siempre junto al nivel del señuelo.

Ejercicio 2

Antes del primer acceso (días −5 a 0), responsable Sara con Lucía:

• Ticket de alta con perfil «desarrollo» aprobado por Marta —perfiles versionados, no accesos sueltos (06-04)—.
• Portátil preparado y enviado con cifrado de disco activo, clave de recuperación custodiada, MDM inscrito, sin cuenta de administrador para el uso diario y con el gestor de contraseñas preinstalado. Por ser remota, se envía antes de la incorporación para que no haya un solo día de trabajo desde un equipo personal.
• Verificación de identidad reforzada en la entrega remota: la activación de la cuenta y el registro del segundo factor se hacen en videollamada con Sara y con el contrato ya firmado. Es el punto más delicado del onboarding remoto: nadie ha visto a esta persona en una oficina, y una suplantación en este momento entrega credenciales corporativas a un desconocido.
• Aceptación de POL-04 firmada antes del primer acceso. Evidencia: registro con fecha.
• MFA obligatorio: el SSO no permite completar el alta sin segundo factor.

Primera semana, responsable Sara (base) e Iván (rol):

• Sesión de acogida de 2 h en directo por videollamada, no un vídeo grabado: por remoto, el contacto humano inicial es lo que hace que después se atreva a preguntar.
• Contenido de la base común: gestor de contraseñas con migración guiada, cómo reconocer un correo sospechoso, cómo se reporta (con una prueba real: reporta un correo de ejemplo el primer día y recibe respuesta), qué datos de cliente puede ver y qué no puede exportar.
• A quién preguntar, con nombres y canales, y el mensaje explícito de que preguntar nunca molesta. En remoto esto hay que decirlo, porque la barrera para interrumpir es más alta.
• Nada de acceso a datos reales de cliente hasta completar la acogida. Trabaja contra el entorno de preproducción con datos seudonimizados (03-07, 06-03).
• Específico de desarrollo: alta en el repositorio con CODEOWNERS, configuración del pre-commit con gitleaks, recorrido por la checklist de revisión de 05-05 y por POL-07.

Primer mes:

• El incidente de 02-06 contado en 8 minutos por Marta. Es lo que da sentido a todas las reglas anteriores.
• Taller de OWASP con el código de Nimbus (apartado 11), incluido el ejercicio de romper un control y comprobar que el CI la detiene.
• Primer simulacro de phishing no puntuado y explícitamente presentado como práctica.
• Presentación de Iván como campeón de seguridad de su área.
• Revisión de accesos a los 30 días: comprobar que el perfil concedido es el que usa de verdad, y retirar lo que sobre. Es mínimo privilegio aplicado en el único momento en que es fácil hacerlo.

Qué se hace distinto por remoto: entrega y verificación de identidad reforzadas; acceso exclusivo por WireGuard (05-04) con instalación asistida; regla explícita sobre wifi doméstica y pública, y sobre no compartir el equipo con la familia; y una conversación de seguimiento a las dos semanas, porque la persona remota no absorbe por ósmosis lo que se comenta en la oficina y es la que con más facilidad se queda fuera de la cultura.

Evidencia que queda (para 06-04): ticket de alta con aprobación y perfil, aceptación firmada de POL-04 con fecha anterior al primer acceso, registro del MFA activado, informe del MDM con el equipo cifrado y clave custodiada, registro de asistencia a la acogida y al taller, y acta de la revisión de accesos a los 30 días.

Ejercicio 3

Respuesta a Marta.

«Los datos dicen lo contrario de lo que parecen. La tasa de clic no es comparable entre campañas de distinta dificultad: la de Q1 de 2026 era un señuelo básico con dominio evidente y urgencia genérica; la de Q1 de 2027 era un señuelo dirigido, sin faltas y con referencia a un proyecto interno real. Que solo el 31 % picara con un señuelo así es un buen resultado, no uno malo.

Lo que sí es comparable, porque mide capacidad y no dificultad, es lo siguiente. La tasa de reporte pasó del 15,8 % al 69,2 %: se ha multiplicado por más de cuatro y hoy dos de cada tres personas avisan. El tiempo hasta el primer reporte cayó de 47 minutos a 4: en un ataque real tendríamos aviso antes de que el atacante terminara de autenticarse, con tiempo para revocar la sesión y rotar la credencial mientras el ataque está en curso. Y las credenciales introducidas pasaron de 4 a 0, que es el único número que mide daño real.

Traducido a lo que nos importa: en el incidente de 02-06 tardamos 20 días en enterarnos. Hoy, ante el mismo vector, tendríamos aviso en 4 minutos.

Sobre tu propuesta, te pido que no la hagamos, por tres razones. Un curso obligatorio adicional no movería estos números, porque el problema nunca fue de conocimiento: la gente ya sabe qué es el phishing y aun así el 31 % pica ante un señuelo bueno —y seguirá picando, porque un señuelo suficientemente bueno engaña a cualquiera—. Anunciar consecuencias para quien pique destruiría precisamente el número que hemos conseguido mover: hoy la gente reporta en 4 minutos porque no teme contarlo; en cuanto haya una conversación con el responsable de por medio, dudarán unos minutos, luego una hora, luego lo callarán. Cambiaríamos unos pocos clics evitados por volver a la ceguera. Y el riesgo que nos hace daño no es el clic, es el tiempo hasta saberlo: eso es lo que decidió la gravedad de 02-06.»

Tres acciones para el trimestre siguiente:

Y una acción de encuadre que no cuesta nada: fijar que las campañas se comparan siempre contra otras del mismo nivel de dificultad, y publicar el nivel junto al resultado. La mitad de las malas decisiones sobre programas de concienciación vienen de comparar números que no son comparables.

Has visto por qué la formación en seguridad no es «la charla anual obligatoria» y por qué el curso de cuatro horas con test final fracasa: la curva del olvido, la distancia entre saber y hacer, el momento equivocado y —lo peor— que enseña a temer el error en lugar de a reportarlo. De ahí el cambio de objetivo que ordena toda la lección: no se trata de que nadie caiga nunca, porque un phishing suficientemente bueno engaña a cualquiera, sino de que cuando alguien caiga se sepa en minutos. Con la frase que lo resume: el error no es el incidente; el silencio sí.

Distingues concienciación, formación y cultura —atención sostenida, capacidad y comportamiento por defecto—, con sus formatos, frecuencias y horizontes distintos, y sabes que ninguna sustituye a las otras. Tienes el análisis de necesidades por rol con lo que cada perfil de Nimbus debe hacer, no solo saber: Marta decidiendo con un registro de riesgos, Iván escribiendo autorización correcta, Lucía ejecutando RB-01, Rubén verificando identidad por canal registrado, Sara verificando un cambio de cuenta bancaria, y una base común corta para todos. Y el programa anual completo en yaml, con doce píldoras temáticas, cuatro simulacros, talleres por rol y tabletop semestral, dentro de 1.400 € y 6 horas por persona sin rol técnico, con el argumento del aprendizaje espaciado detrás.

Sabes montar la acogida —aceptación de POL-04 y MFA antes del primer acceso, gestor de contraseñas instalado con acompañamiento, nada de datos reales hasta completarla— y la salida, con su revocación en 24 horas, su recordatorio de confidencialidad y la pregunta que más mitiga R-09: qué sabes que no está escrito. Y el eslabón olvidado del cambio de puesto, que se trata como una baja seguida de un alta para no acumular privilegios. Conoces los formatos que funcionan, con el aviso contextual como el de mejor retorno —no enseña nada y cambia comportamiento— y con la regla sobre el material comprado: compra el marco, produce tú los ejemplos, porque Marta contando el incidente de 02-06 en ocho minutos vale por diez cursos genéricos.

Sabes diseñar simulacros de phishing bien hechos: objetivo declarado de medir y entrenar el reporte, cuatro niveles de dificultad, la regla ética que prohíbe señuelos sobre nóminas, despidos, ayudas o salud —porque funcionan siempre y por eso no miden nada—, formación inmediata y privada para quien pica y nunca una lista pública. Y sabes leer los datos: la tabla de tres campañas de Nimbus, donde la tasa de clic sube y el programa ha mejorado enormemente porque la tasa de reporte se multiplicó por cuatro, el tiempo al primer reporte cayó de 47 minutos a 4 y las credenciales introducidas pasaron de 4 a 0. Con la regla que conviene escribir antes de la primera campaña: la tasa de clic mide la dificultad del señuelo; la tasa de reporte y el tiempo al primer reporte miden la salud del programa.

Tienes el botón de reportar con sus cinco requisitos —un gesto, disponible donde ocurre el riesgo, respuesta el mismo día, agradecimiento sin excepción y sin fricción emocional— y su circuito completo hasta el runbook, con las dos consecuencias que sorprenden: los falsos positivos son buena señal y el volumen de reportes mide confianza, no amenaza. Comprendes la cultura justa y su tabla de error humano, conducta arriesgada, temeridad y dolo, con el razonamiento económico que la sostiene: culpar al que pica compra ceguera a cambio de nada, porque cambia unos pocos clics evitados por un aumento enorme del tiempo de detección. Sabes medir el programa separando indicadores de vanidad de indicadores de comportamiento, con el más ignorado de todos —las consultas preventivas— como mejor señal temprana de cambio cultural. Y sabes escalar con campeones de seguridad con horas explícitas, formar a desarrollo con el código real de Nimbus incluido el ejercicio de romper un control para ver que el CI te detiene, y formar a la dirección, que es quien más decide, quien más responsabilidad legal asume desde NIS2 y quien más daño hace al programa si se salta sus propios controles.

Y queda una última pieza. Todo lo que hemos construido —controles, evidencias, hábitos, programas— presupone que quien maneja este conocimiento lo usa bien. Pero el mismo saber que permite defender permite atacar; el mismo nmap que verifica tu segmentación escanea la red de otro; la misma persona que encuentra un fallo en tu API puede encontrarlo en la de un tercero y no saber qué hacer con él. ¿Dónde está exactamente la línea legal? ¿Qué hace válida a una autorización? ¿Qué haces si tu empresa te pide algo que no debes hacer? ¿Y cómo se reporta —y cómo se recibe— una vulnerabilidad? En Ética, Aspectos Legales y Divulgación Responsable (06-06) cerramos el módulo y la parte lectiva del curso con lo que 05-03 dejó pendiente: el Código Penal español aplicado a lo informático, el marco de la divulgación responsable, la política que Nimbus debe publicar para recibir avisos, y la responsabilidad de quien sabe hacer esto.