El módulo 5 terminó con una advertencia incómoda: nada de lo construido se mantiene solo. El escaneo mensual deja de ejecutarse cuando Lucía tiene una semana mala, la línea base se degrada si nadie mira el --check --diff, la CSP se llena de excepciones y el security.txt caduca. Esta lección trata el problema que sostiene a todos los demás: cómo se convierte una decisión puntual en un hábito que sobrevive a las vacaciones, a las bajas, a un lanzamiento urgente y a la rotación de personal. No hay ninguna herramienta nueva aquí. Hay checklists por rol, un calendario, automatismos que no dependen de la memoria de nadie, un cuadro de mando de diez números y una hoja de ruta de doce meses que cabe en 18.000 € y 440 horas. Es la lección menos espectacular del curso y probablemente la que más incidentes evita.

1. La tesis: la seguridad no se consigue, se sostiene
2. Higiene de seguridad: lo poco que evita casi todo
3. Buenas prácticas por rol: seis checklists
4. Ritmos y cadencias: el calendario de seguridad de Nimbus
5. Automatizar el hábito: que el sistema recuerde por ti
6. Medir para no engañarse: el cuadro de mando mínimo
7. Mejora continua: PDCA y la regla de terminar antes de empezar
8. Antipatrones organizativos
9. Cultura: cómo se reconoce la de verdad
10. La hoja de ruta de 12 meses de Nimbus

Hay un dato que debería incomodar a cualquiera que lleve tiempo en esto: en la inmensa mayoría de los incidentes graves, la organización afectada sabía lo que había que hacer. No le faltaba conocimiento. Repasa los casos de 02-06 con esta lente:

La conclusión no es que la gente sea negligente. Es que saber y hacer son dos capacidades distintas, y la segunda se degrada con el tiempo salvo que exista un mecanismo que la sostenga. Un proyecto de seguridad produce un estado bueno en una fecha concreta; a partir de ahí, el estado se degrada solo. Se despliegan servidores nuevos, se contrata gente, se abren puertos «temporalmente», se crean cuentas de servicio para una migración, se instalan dependencias. Es lo que en 01-04 llamamos deriva de la configuración y en 05-06 combatíamos con Ansible: la entropía es la condición por defecto.

Un hábito, en cambio, es una acción que se ejecuta sin decisión previa porque hay un disparador que la lanza. La diferencia práctica es esta:

• Proyecto: «vamos a poner MFA a todo el mundo». Termina, se celebra, y seis meses después el 30 % de las cuentas nuevas no lo tiene.
• Hábito: «ninguna cuenta se crea sin MFA porque el proveedor de identidad no lo permite, y el primer lunes de mes sale un informe con las excepciones». No termina nunca, y por eso funciona.

La pregunta que ordena toda esta lección no es «¿lo hemos hecho?», sino «¿qué hace que se siga haciendo dentro de un año, cuando nadie se acuerde de esta conversación?».

La higiene de seguridad es el conjunto reducido de prácticas básicas cuya ausencia explica la mayoría de los incidentes. El término es deliberado: como lavarse las manos, no es glamuroso, no requiere talento y su efecto agregado supera a cualquier intervención sofisticada.

Ocho prácticas. No son ocho entre muchas: son las ocho.

El argumento de por qué esto basta para casi todo tiene dos patas. La primera es estadística: los informes anuales del sector (Verizon DBIR, ENISA, INCIBE) coinciden año tras año en que la gran mayoría de las brechas empiezan por credenciales, phishing, explotación de vulnerabilidad conocida o error de configuración —los cuatro primeros de la lista—. La segunda es económica: el atacante que ataca a Nimbus no es un servicio de inteligencia, es un operador oportunista que barre Internet buscando lo fácil, y la higiene lo convierte en un objetivo caro.

La regla que conviene grabarse: lo básico bien mantenido supera a lo avanzado mal mantenido. Un EDR de gama alta con la mitad de los endpoints sin agente y las alertas sin revisar protege menos que MFA universal más copias probadas. Y cuesta veinte veces más.

Fíjate en el detalle que separa la higiene real de la aparente: cada una de las ocho lleva un verbo de verificación. No es «hacer copias», es «probar la restauración». No es «tener inventario», es «actualizarlo». No es «poner alertas», es «revisarlas». El verbo de verificación es lo que convierte una intención en un hábito medible.

Una lista de buenas prácticas dirigida a «la empresa» no la ejecuta nadie. Dirigida a una persona con nombre, sí. Estas son las seis checklists de Nimbus, redactadas para que quepan en una tarjeta.

• Asigno tiempo, no solo presupuesto. Las 440 h de Lucía están en el plan como cualquier proyecto de producto; si no lo están, no existen.
• Reviso mensualmente el registro de cambios privilegiados (C-21) y firmo el acta. Quince minutos.
• Reviso trimestralmente el registro de riesgos de 04-01 y el registro de excepciones: qué ha cambiado, qué excepción caduca.
• Ninguna excepción sin fecha de caducidad. La excepción de 2023 de la consultora, sin caducidad, es la razón por la que existe el incidente de 02-06.
• El riesgo entra en las decisiones de producto. Cuando comercial promete una integración para el viernes, la pregunta «¿qué datos toca y quién los ve?» la hago yo, no la espero de otro.
• Un incidente reportado tarde es mi fallo, no del que lo reportó. Lo digo en voz alta y actúo en consecuencia.
• Firmo lo que apruebo y conservo la aprobación: políticas, excepciones, presupuesto. Es la evidencia de 06-04.

• No confío en ningún dato que venga del cliente, incluidos los identificadores: la autorización se decide en el servidor con tenant_actual y exige(), nunca con un parámetro.
• Ningún secreto en el código, ni en .env versionado, ni en un log. Gestor de secretos siempre; gitleaks bloquea el commit si me despisto.
• Dependencias fijadas y auditadas: pip-audit en el CI, actualización mensual, y no añado una librería sin mirar quién la mantiene.
• Las pruebas de autorización son pruebas, no revisión manual: cada endpoint nuevo lleva un test que verifica que el tenant B no ve al tenant A.
• Registro lo relevante y nada más: quién, qué, cuándo, sobre qué recurso; nunca contraseñas, tokens, ni el contenido de una nota clínica.
• Antes de abrir un pull request, paso la checklist de revisión de 05-05. Si toco autenticación, autorización, criptografía o subida de ficheros, lo marco para que lo mire alguien más.
• Cuando encuentro un fallo de seguridad en nuestro código, lo digo el mismo día. No lo arreglo en silencio.

• Reviso las alertas del día, todas, y cierro cada una con una frase de qué era. Una alerta sin cerrar es una alerta que no existe.
• Aplico parches críticos en 7 días y dejo constancia de la fecha; los demás, en la ventana mensual.
• Cambio de infraestructura = código. Nada a mano en la consola: si no está en Terraform o en Ansible, no ha pasado.
• Ejecuto --check --diff semanal y trato cualquier deriva como un incidente menor: alguien tocó algo fuera de proceso.
• Pruebo la restauración cada trimestre con cronómetro y guardo el informe. Sin ese informe, las copias son una creencia.
• Ningún acceso permanente para terceros: la consultora entra just-in-time, con ventana de 8 horas y revocación automática.
• Documento mientras hago, no después. Un runbook escrito a posteriori nunca se escribe.
• Cuando algo urgente me obliga a saltarme el proceso, abro la excepción con fecha de cierre antes de saltármelo.

• Verifico la identidad antes de tocar nada: nunca por la información que la persona me da, sino por un canal que ya tenemos registrado.
• Nunca pido ni acepto una contraseña, ni «para comprobar». Si alguien insiste, es la señal.
• Accedo al mínimo de tenants: cada acceso queda en la tabla de auditoría y la detección D-05 mira exactamente eso.
• No exporto datos a mi correo ni a mi portátil. Si necesito un informe, sale del sistema con URL firmada y caduca.
• Una petición urgente y emotiva de un cliente es un patrón de ingeniería social. La urgencia es la herramienta, no el contexto.
• Reporto lo raro aunque parezca una tontería. Tres llamadas de clínicas quejándose de lentitud fueron, en 02-06, el día 20.

• Ningún cambio de cuenta bancaria de un proveedor sin verificación por canal alternativo, llamando al número que ya teníamos, no al del correo.
• Ninguna transferencia fuera del circuito habitual por urgencia de dirección. Ese es literalmente el guion del fraude del CEO.
• Las altas y bajas de personal se comunican el mismo día: la baja dispara la revocación de accesos (02-05), y una baja comunicada tarde es una cuenta viva sin dueño.
• Los datos de RRHH (A-16) viven donde deben vivir, no en una hoja de cálculo en el escritorio ni en una carpeta compartida con toda la empresa.
• Los currículos y contratos son datos personales. Se conservan el tiempo previsto y luego se borran (06-03).
• Facturas y adjuntos inesperados no se abren: se comprueba el remitente real, no el nombre mostrado.

• Gestor de contraseñas para todo, contraseñas únicas, MFA donde se ofrezca.
• Portátil cifrado, bloqueo automático, sin trabajar como administrador en el día a día.
• Actualizo cuando el sistema lo pide, y no aplazo indefinidamente.
• Ante la duda, pregunto antes de hacer clic. Preguntar nunca es una molestia.
• Reporto con el botón, incluso si ya he picado. Sobre todo si ya he picado.
• No instalo herramientas ni conecto servicios externos a los datos de la empresa sin pasar por Marta y Lucía.
• Wifi de invitados para dispositivos personales, nunca la corporativa.

Un hábito necesita un disparador temporal. Esta es la traducción de todo el curso a un calendario, expresado como dato para que pueda vivir en el repositorio y generar recordatorios automáticos.

Cómo se lee este calendario. Sumando el tiempo recurrente sale en torno a 300 horas al año de Lucía y unas 60 de Marta, más el presupuesto del pentest. Está dentro de las 440 h disponibles, y deja unas 140 para proyectos de mejora. Esa cuenta —que casi nadie hace— es la que evita el error clásico de planificar un año lleno de proyectos nuevos sin dejar espacio para operar lo ya construido.

Tres criterios de diseño del calendario que conviene entender:

• Lo diario es corto o no se hace. Quince minutos se sostienen; una hora diaria no.
• Lo caro va espaciado y con evidencia obligatoria. La prueba de restauración es trimestral porque cuesta media jornada, y produce un informe porque si no, nadie sabrá si se hizo.
• Cada tarea tiene dueño nominal. «El equipo» no ejecuta nada.

Un calendario sigue dependiendo de que alguien lo mire. El siguiente escalón es convertir la práctica en algo que el sistema fuerza, de modo que omitirla requiera un acto deliberado en lugar de un descuido.

El ejemplo más barato y más olvidado es la plantilla de pull request, que convierte la checklist de 05-05 en algo que aparece delante de los ojos en el momento exacto:

Y el patrón general que hay detrás de todos los ejemplos: valores por defecto seguros. Si la plantilla de Terraform con la que se crea un bucket ya trae bloqueo público, cifrado y versionado, nadie tendrá que acordarse. Si la imagen base ya es distroless y sin root, ningún desarrollador tendrá que decidirlo. La forma más eficaz de sostener una buena práctica es hacer que la opción segura sea también la más cómoda.

Un aviso: automatizar sin revisar produce una falsa sensación de control. Un CI que falla siempre acaba con la gente usando --no-verify. Regla práctica: si un control automático produce más de un falso positivo por semana, arréglalo o quítalo, porque en poco tiempo lo van a ignorar de todas formas.

Sin medida, la percepción de seguridad sube con el esfuerzo invertido, no con el riesgo real. El antídoto es un cuadro pequeño de indicadores que se publica cada mes, siempre los mismos, con su objetivo y su fuente. Diez números para Nimbus:

Cuatro reglas para que el cuadro no se convierta en decoración:

• Cada indicador tiene un objetivo declarado antes de medirlo. Si el objetivo se fija después, siempre se cumple.
• Cada indicador tiene una fuente automatizable. Si el dato requiere que alguien lo estime, es una opinión.
• Se publica aunque salga mal. Un cuadro que solo se enseña cuando está verde no informa de nada.
• Se mira la tendencia, no el valor absoluto. Un 92 % que sube vale más que un 96 % que baja.

Un cálculo automatizado, en la línea del de 04-03 pero ya como cuadro completo:

Salida:

Compara con el cuadro de 04-03: entonces el MFA estaba al 57 % y el parcheo por encima de plazo. La mejora es real y es medible, y ese es exactamente el punto. Los cinco indicadores en rojo no son un fracaso: son la lista de trabajo del mes, y dos de ellos —el portátil sin cifrar y las excepciones caducadas— se cierran en una tarde.

El ciclo PDCA (Planificar, Hacer, Verificar, Actuar) es el motor formal de la mejora continua, y es la estructura que la ISO 27001 exige en su cláusula 10 (lo veremos en 06-02). Aplicado a Nimbus, sin liturgia:

Lo que hace útil al ciclo no es dibujarlo, sino dos disciplinas concretas:

Cómo se prioriza cuando todo parece urgente. El orden de Nimbus, en este orden exacto:

1. Lo que está ardiendo: incidente en curso, vulnerabilidad crítica con exploit activo (KEV, en la terminología de 05-01).
2. Lo que reduce más riesgo por euro y por hora, según el ALE del registro de 04-01. Sigue siendo el criterio de fondo.
3. Lo que es gratis y rápido: cerrar un puerto, marcar una casilla, poner una fecha de caducidad a una excepción. Se hace ya, no se planifica.
4. Lo que sostiene lo demás: automatismos, calendario, documentación. Se subestima siempre y es lo que evita rehacer.
5. Lo que exige un cliente o una norma con fecha, aunque no sea lo más eficaz. Es un riesgo de negocio real.
6. Lo que es interesante. Al final. Siempre al final.

La regla de terminar antes de empezar. Nimbus no arranca una iniciativa nueva mientras haya más de dos en curso. Suena burocrático y es lo contrario: la seguridad a medias no protege proporcionalmente. Un despliegue de MFA al 60 % no reduce el riesgo un 60 %, porque el atacante busca precisamente el 40 % restante. Un control a medias suele valer cero. Por eso conviene elegir tres cosas al trimestre, terminarlas, verificarlas y solo entonces abrir las siguientes.

Cinco formas de tener seguridad sobre el papel y no tenerla en la práctica. Las cinco son culturales, no técnicas.

Merece un párrafo el caso de Lucía y el riesgo de bus, porque es el más común en las PYME y el peor entendido. R-09 tiene impacto alto y probabilidad nada despreciable —basta una baja médica o una oferta mejor—. Y no se resuelve con un documento: se resuelve reduciendo el conocimiento tácito. Tres medidas concretas, ninguna cara:

• Documentación operativa (A-17) escrita durante la ejecución, con el criterio de que otra persona técnica pueda seguirla sin preguntar.
• Rotación mínima: Iván ejecuta la prueba de restauración trimestral al menos una vez al año, con Lucía observando. La primera vez saldrá mal, y ese es justamente el hallazgo.
• Retenedor externo de guardia con la consultora, ahora con acceso just-in-time, para cubrir vacaciones. Y con la lección de 02-06 bien aprendida: el retenedor no vuelve a implicar acceso permanente.

Sobre comprar sin operar, la aritmética de una PYME es implacable: un SIEM comercial de 12.000 €/año consume dos tercios del presupuesto de Nimbus y exige entre 100 y 200 horas anuales de operación que Lucía no tiene. Con esas mismas 200 horas se implantan las doce detecciones D-01…D-12 sobre herramientas abiertas, se prueban y se automatiza el calendario. La pregunta previa a cualquier compra es quién la va a operar, con qué horas y quién se enterará si deja de funcionar.

La cultura de seguridad no se mide por carteles ni por el porcentaje de finalización del cursillo anual —eso es 06-05 y allí veremos por qué es un indicador de vanidad—. Se reconoce por comportamientos observables:

• Se reportan los errores propios sin miedo. Alguien dice «he hecho clic en un enlace raro» a los cinco minutos, no al día siguiente ni nunca. Este es el indicador principal: donde se castiga al que pica, la detección temprana desaparece.
• Se pregunta antes de actuar. «¿Puedo mandar este export al cliente por correo?» es una pregunta sana, y la respuesta debe llegar el mismo día o la gente dejará de preguntar.
• El riesgo se dice en voz alta en las decisiones de producto, no solo en las reuniones de seguridad. «Esto expone el identificador del tenant en la URL» se dice en el refinamiento, no en el pentest.
• Se puede decir que algo va mal hacia arriba. Si Lucía puede decirle a Marta «no llegamos a esto y el riesgo es X» sin coste personal, el sistema funciona.
• Lo temporal tiene fecha. El bucket de pruebas, la regla de firewall de un día, el acceso para una migración: si nacen con fecha de caducidad, hay cultura; si no, hay deuda.
• Cuando algo falla, se pregunta qué del sistema lo permitió, no quién lo hizo. Es el post mortem sin culpables de 04-05 aplicado a lo cotidiano.

La cultura no se decreta; se produce por lo que la dirección premia, tolera e ignora. Si Marta agradece públicamente un reporte que resultó falsa alarma, ha comprado más seguridad que con cualquier herramienta de ese precio.

Todo lo anterior converge aquí: un plan anual que integra el curso completo, con dueño, coste y resultado esperado, dentro de 18.000 € y 440 horas de Lucía (de las cuales unas 300 ya se consumen en el calendario recurrente del apartado 4, así que el margen de proyecto es de unas 140 h, más el tiempo de Iván, Marta y Sara).

Cómo se defiende este plan ante la dirección, que es lo que hará que se apruebe: no se presenta como catorce tareas técnicas, sino como la cobertura de los riesgos peor puntuados del registro de 04-01. R-01 (ransomware por tercero, ALE 96.000 €) queda cubierto en T1-T2 con cuatro iniciativas que suman 1.100 €. R-02 (destrucción de copias) cae en T2 por 400 €. R-06 (secretos) en T1 por 300 €. R-03 y R-07 en T3. Un plan de 18.000 € que ataca directamente un riesgo anual esperado muy superior es una conversación de negocio, no una petición de presupuesto.

• Confundir actividad con progreso. Diez iniciativas al 40 % dan una sensación excelente y una reducción de riesgo cercana a cero. Termina tres.
• Escribir el calendario y no ponerle dueño ni evidencia. Una tarea sin dueño no se hace; una tarea sin evidencia no se puede saber si se hizo. Ambas cosas son igual de fatales.
• Planificar el año con el 100 % del tiempo en proyectos nuevos. Si el calendario recurrente consume 300 de las 440 horas, planificar 400 horas de proyectos garantiza que la operación se caiga o que los proyectos no acaben. Reserva el tiempo de operación primero.
• Medir lo fácil en lugar de lo que importa. «Horas de formación impartidas» es cómodo y no dice nada; «tasa de reporte de phishing» es incómodo y sí.
• Tratar la automatización como un fin. Automatizar un control que nadie revisa produce un registro que nadie lee. Automatiza la ejecución y la notificación de fallo.
• Consejo: empieza por el calendario, no por la herramienta. Si mañana solo pudieras hacer una cosa de esta lección, crea las catorce tareas recurrentes del apartado 4 con dueño y fecha. Cuesta una hora y es lo que más cambia.
• Consejo: pon fecha de caducidad a todo lo temporal, por sistema y sin excepciones: la mayor parte de la deuda de seguridad de cualquier empresa es «temporal» de hace tres años. Y publica el cuadro de mando aunque esté en rojo: el primer mes duele; el tercero, la gente empieza a competir por ponerlo en verde.

Ejercicio 1 — De proyecto a hábito

Nimbus acaba de terminar una iniciativa: se ha verificado que los 40 portátiles tienen el disco cifrado y se ha guardado la evidencia. Marta lo da por cerrado. Explica por qué este control se habrá degradado dentro de doce meses si no se hace nada más, e indica tres mecanismos concretos —uno de calendario, uno automatizado y uno de valor por defecto— que lo conviertan en un hábito. Para cada uno, di qué evidencia produce.

Ejercicio 2 — Rediseñar una práctica frágil

Esta es la práctica actual de Nimbus para el alta de un empleado nuevo, tal como la ejecuta Sara: «Cuando entra alguien, aviso a Lucía por chat y ella le crea las cuentas que necesite». Identifica cuatro fallos de esta práctica desde el punto de vista de la sostenibilidad y del control de accesos, y reescríbela en un formato que resista a que Sara esté de vacaciones, a que Lucía tenga un día malo y a la pregunta de un auditor seis meses después.

Ejercicio 3 — Priorizar con el presupuesto agotado

Estamos en octubre. Quedan 1.800 € y 35 horas de Lucía. Sobre la mesa hay cuatro peticiones: (a) un cliente grande exige respuesta a un cuestionario de seguridad de 90 preguntas antes de renovar; (b) el cuadro de mando marca 2 excepciones caducadas y 1 portátil sin cifrar; (c) Iván quiere migrar a una imagen base distroless en todos los servicios; (d) ha salido una vulnerabilidad crítica con exploit público en una librería que usa la API. Ordénalas justificando el criterio y di qué harías con las horas y el dinero.

Ejercicio 1

Por qué se degrada. El control se verificó sobre una foto fija de 40 portátiles en una fecha. En doce meses habrán ocurrido, con casi total seguridad: entradas de personal nuevo con portátiles recién comprados (que llegan con cifrado desactivado o con clave de recuperación no custodiada), reinstalaciones tras una avería, algún equipo personal usado temporalmente «mientras llega el nuevo» y algún cambio de sistema operativo. Ninguna de esas situaciones tiene un mecanismo que reactive el control. La evidencia guardada seguirá siendo válida como prueba de lo que pasó ese día, pero no dice nada del estado actual, y esa confusión —evidencia histórica leída como estado presente— es el error de fondo.

Tres mecanismos:

1. Calendario: entrada mensual en el calendario-seguridad.yml con dueño Lucía, 10 minutos, «verificar cobertura de cifrado del parque frente al inventario de equipos activos». Evidencia: informe mensual con numerador (cifrados), denominador (equipos activos) y lista nominal de excepciones. Alimenta el indicador 3 del cuadro de mando.
2. Automatizado: consulta osquery programada que reporta el estado de cifrado de cada equipo al inventario, más una alerta —no un informe— cuando aparece un equipo activo con cifrado desactivado o con clave de recuperación no depositada. La diferencia entre informe y alerta es la que separa detectar en 30 días de detectar en 1. Evidencia: histórico de la consulta y registro de alertas con su cierre.
3. Valor por defecto: la política del MDM exige cifrado activo y clave custodiada como condición para acceder al correo y a los recursos corporativos. Un portátil no cifrado deja de ser útil, con lo que el incumplimiento se hace visible en horas y sin intervención de nadie. Evidencia: exportación de la política del MDM y lista de dispositivos conformes/no conformes.

Los tres son complementarios: el tercero impide, el segundo detecta rápido y el primero demuestra ante un cliente o un auditor. Un cuarto elemento cierra el círculo: incluir «verificar cifrado y custodia de la clave» en el checklist de entrega de equipo del proceso de alta, para atacar la causa en origen.

Ejercicio 2

Cuatro fallos:

1. No hay definición previa de qué accesos corresponden al puesto. «Las cuentas que necesite» significa que Lucía improvisa, y ante la duda concede de más, que es exactamente cómo mueren el mínimo privilegio y el control C-18.
2. El disparador es un mensaje de chat, un canal efímero, sin trazabilidad y que depende de que Sara esté trabajando ese día. Si Sara está de vacaciones, el alta no se dispara o la dispara alguien de forma distinta.
3. No hay aprobación registrada. Nadie con autoridad ha dicho por escrito que esa persona deba tener esos accesos. Es lo primero que pide un auditor (06-04) y no existe.
4. No hay simetría con la baja. El proceso de alta no crea ningún registro de qué se concedió, así que en la salida nadie sabrá qué revocar. Es el origen de las cuentas huérfanas de 02-05.

Práctica reescrita:

Lo que hace resistente a esta versión: el disparador es un artefacto persistente y no una persona; los accesos son perfiles versionados y no decisiones improvisadas; la aprobación queda registrada; el MFA y el cifrado están forzados por el sistema; hay suplencia explícita; y el propio proceso produce la evidencia que la baja, la recertificación semestral y el auditor van a necesitar. Coste de montarlo: una tarde.

Ejercicio 3

Orden: (d), (b), (a), (c).

• (d) Vulnerabilidad crítica con exploit público va primero por el criterio 1 del apartado 7: está ardiendo. Un exploit público en una librería de la API significa que el escaneo automatizado de terceros la encontrará en días —es exactamente el patrón de Equifax—. Consume 8 horas de Lucía e Iván (actualizar, probar, desplegar, verificar) y 0 €. No se negocia ni se planifica: se hace hoy.
• (b) Las dos excepciones caducadas y el portátil sin cifrar van después por el criterio 3: es gratis y rápido. Cerrar o renovar formalmente dos excepciones son 2 horas de Marta; cifrar un portátil es 1 hora. 3 horas, 0 €, y pone dos indicadores del cuadro de mando en verde. Además, si el cliente de (a) pregunta por gestión de excepciones, la respuesta ya será buena.
• (a) El cuestionario del cliente es un riesgo de negocio con fecha, criterio 5. Consume 20 horas y probablemente 0 € si se responde internamente. Y hay una inversión implícita que conviene hacer bien: al responderlo, se construye el dosier de seguridad reutilizable de 06-04, de modo que el siguiente cuestionario cueste 4 horas en lugar de 20. Es la diferencia entre gastar y invertir.
• (c) La migración a distroless se aplaza al plan del año siguiente. Es una mejora real y estructural, pero ningún riesgo del registro depende de ella con urgencia, no hay fecha externa y consumiría todas las horas restantes dejando (a) sin hacer. Se documenta en el plan de T1 del próximo ejercicio para que no se pierda —aplazar no es descartar, y la diferencia entre ambas cosas es escribirlo—.

Reparto final: 31 horas de las 35, y 0 € de los 1.800. El dinero sobrante no se gasta por gastarlo: se reserva. Si en noviembre aparece otra crítica que exija ayuda externa, tener 1.800 € libres vale más que un año de licencia de una herramienta que nadie va a operar. Y si llega diciembre sin usarlo, refuerza la petición de presupuesto del año siguiente: una organización que no gasta por gastar es una organización a la que se le confía el presupuesto.

Has visto la tesis que sostiene todo el módulo: la seguridad no se consigue con proyectos, se sostiene con hábitos, y la prueba es que en casi todos los grandes incidentes —incluido el de Nimbus— la organización sabía perfectamente lo que había que hacer. Lo que faltó no fue conocimiento, sino un mecanismo que garantizara que se seguía haciendo. De ahí la pregunta que ordena la lección: no «¿lo hemos hecho?», sino «¿qué hace que se siga haciendo dentro de un año?».

Conoces las ocho prácticas de higiene —MFA, parcheo con plazo, copias probadas, mínimo privilegio, inventario, formación y reporte, registro y alerta, cifrado por defecto— y por qué bastan para casi todo: por estadística, porque explican la gran mayoría de las brechas, y por economía, porque convierten a Nimbus en un objetivo caro para un atacante oportunista. Con la regla que resume el apartado: lo básico bien mantenido supera a lo avanzado mal mantenido, y con el detalle que distingue la higiene real de la aparente, que es el verbo de verificación de cada práctica.

Tienes las seis checklists por rol —Marta, Iván, Lucía, Rubén, Sara y cualquier empleado— redactadas para caber en una tarjeta y para que cada persona sepa qué le toca sin traducir nada. Tienes el calendario de seguridad de Nimbus como dato en yaml, con lo diario, semanal, mensual, trimestral, semestral y anual, cada tarea con dueño, tiempo y evidencia esperada; y la cuenta que casi nadie hace: 300 de las 440 horas ya están comprometidas en operar lo construido, lo que deja 140 para mejorar. Sabes automatizar el hábito, convirtiendo cada práctica frágil en algo forzado por el sistema —gitleaks bloqueante, MFA imposible de omitir, plantilla de pull request, MDM que exige cifrado, ACME que renueva—, con el principio de fondo de que la opción segura debe ser también la más cómoda, y con la advertencia de que un control automático ruidoso acaba ignorado.

Sabes medir para no engañarte con un cuadro de diez indicadores, su objetivo, su fuente y su cálculo automatizado, y con las cuatro reglas que lo mantienen honesto —objetivo antes de medir, fuente automatizable, publicación aunque salga rojo, tendencia sobre valor absoluto—. Manejas el ciclo PDCA, el orden de prioridad cuando todo parece urgente y la regla de terminar antes de empezar, que se apoya en un hecho poco intuitivo: un control a medias suele valer cero. Reconoces los cinco antipatrones organizativos —el departamento del no, el proyecto que termina, el cumplimiento como sustituto, la persona única y comprar sin capacidad de operar— con el caso de Lucía y el riesgo de bus, y la pregunta que debe preceder a cualquier compra: quién lo opera y con cuántas horas. Y sabes reconocer la cultura real por comportamientos observables, empezando por el más importante: que la gente reporte sus propios errores el mismo día y sin miedo. Todo ello cristalizado en la hoja de ruta de 12 meses, catorce iniciativas con dueño, coste y resultado medible, que cabe exactamente en 18.000 € y 380 horas y que se defiende ante la dirección como cobertura de los riesgos peor puntuados, no como una lista de tareas técnicas.

Ahora bien, este calendario y esta hoja de ruta los ha decidido Nimbus por su cuenta, mirando su propio riesgo. Y esa libertad tiene un límite: hay cosas que no se eligen. Cuando una clínica pregunta si Nimbus cumple el RGPD, cuando un cliente institucional exige el Esquema Nacional de Seguridad, cuando la transposición de NIS2 alcanza a los proveedores de sectores regulados o cuando un contrato exige una certificación ISO 27001, la conversación deja de ser sobre prioridades propias y pasa a ser sobre obligaciones ajenas con consecuencias. En Normativas y Estándares de Seguridad (06-02) ordenamos ese mapa: qué es de obligado cumplimiento y qué es voluntario, qué le aplica de verdad a una PYME como Nimbus y qué no, qué es realmente un SGSI y una Declaración de Aplicabilidad, cuánto cuesta y cuánto tarda certificarse, y —lo más útil— cómo se traduce una obligación escrita en lenguaje jurídico en trabajo concreto: requisito, política, control y evidencia.