En la lección anterior construiste el registro de riesgos de Nimbus y tomaste decisiones concretas: MFA obligatorio, acceso just-in-time para la consultora, prohibición de enlaces públicos, secretos en un gestor y no en .env. Todas esas decisiones tienen hoy el mismo problema: viven en la cabeza de tres personas y en un fichero YAML que nadie fuera del equipo técnico lee. Cuando Marta cambie de empresa, cuando entre un empleado nuevo o cuando un cliente pregunte «¿qué reglas tenéis?», ese conocimiento desaparece o no se puede enseñar. Esta lección trata del artefacto que resuelve exactamente eso: la política de seguridad, que es el mecanismo por el que una decisión sobrevive a quien la tomó. Terminarás con una plantilla reutilizable, dos políticas de Nimbus redactadas enteras y un registro de excepciones con caducidad obligatoria.

1. Qué es una política y por qué existe
2. La jerarquía documental: política, norma, procedimiento y guía
3. Un mismo tema por los cuatro niveles: contraseñas y MFA
4. Anatomía de una política y plantilla reutilizable
5. El conjunto mínimo de políticas de una PYME
6. Política de Control de Accesos de Nimbus, redactada entera
7. Política de Uso Aceptable de Nimbus, redactada entera
8. El ciclo de vida de una política
9. Excepciones: solicitud, aprobación y caducidad obligatoria
10. Por qué fracasan las políticas
11. Políticas y marcos normativos: solo el puente

Una política de seguridad es un documento aprobado por la dirección que declara qué se exige y por qué, con carácter obligatorio para las personas incluidas en su alcance. No explica cómo se hace —eso es un procedimiento—, ni lista productos, ni caduca cuando cambia la tecnología. Sirve para cosas que ningún otro artefacto cubre:

La exigibilidad merece una precisión. Si Nimbus quiere poder actuar cuando alguien instala software no autorizado en un portátil corporativo, necesita haber comunicado antes que eso no está permitido, y poder demostrar que lo comunicó. Una regla no escrita ni comunicada no es una regla: es una preferencia.

Y una política no es un manual de instrucciones, que es el error de redacción más frecuente. La política dice «el acceso a datos de producción requiere autenticación multifactor resistente al phishing»; el procedimiento dice «entra en el panel de identidad, pulsa Añadir método, elige Clave de seguridad…». La primera frase seguirá siendo válida dentro de cinco años; la segunda quedará obsoleta con el próximo rediseño del panel.

Fíjate en el ciclo que cierra el diagrama: el registro de riesgos justifica la política, la política se concreta en normas, las normas se ejecutan mediante procedimientos y se materializan en controles, y los controles reducen el riesgo residual del registro que lo empezó todo. Una política que no se puede trazar hasta un riesgo concreto sobra; un riesgo Crítico sin política que lo respalde queda a merced de la memoria de quien lo detectó. Dos errores de nivel muy comunes: meter parámetros en la política —si dice «las contraseñas tendrán 12 caracteres», cambiar a 14 obliga a una nueva aprobación de la dirección; los números van en la norma— y escribir guías con lenguaje de política —si algo es una recomendación tiene que decir «se recomienda»; si dice «debe», es obligatorio y alguien lo auditará—.

Nada aclara la jerarquía como ver un solo tema recorrerla entera. Nivel 1 — Política de Contraseñas y Autenticación (extracto):

Nivel 2 — Norma de Autenticación (extracto): aquí van los números, y por eso puede actualizarse sin molestar a la dirección.

Nivel 3 — Procedimiento «Alta de una passkey» (extracto):

Nivel 4 — Guía «Cómo elegir una contraseña maestra memorable»: frases de paso, uso del gestor y qué hacer si se pierde la clave física. No es obligatoria y nadie la audita. La consecuencia práctica de los cuatro niveles se ve mejor así:

Esa tabla es la razón práctica de la jerarquía: cada cosa en su nivel cambia con su propia frecuencia y la aprueba quien corresponde, y así el sistema documental no se paraliza ni se descontrola.

Una política que le falte alguno de estos apartados generará una discusión el día que importe. Este es el esqueleto y la plantilla que reutilizarás en el proyecto final:

Tres apartados que la gente omite y que son justo los que se echan de menos: el propósito con trazabilidad al riesgo —sin él, dentro de dos años nadie sabrá por qué existe la regla y la primera persona a la que le estorbe la eliminará—; lo que queda fuera del alcance —escribir «esta política no aplica a los dispositivos personales que solo consultan correo» evita la discusión eterna sobre si aplica—; y las excepciones, porque una política sin vía de excepción se incumple en silencio, mientras que con ella el incumplimiento se convierte en una decisión visible y con fecha de caducidad.

Nimbus no necesita las 40 políticas de una multinacional: necesita estas once, y el orden de la columna «Prioridad» sale directamente del registro de riesgos de 04-01.

Dos criterios de PYME que conviene aplicar sin complejos. Empieza por las cinco de prioridad 1 y publica el resto en los seis meses siguientes: once políticas mediocres publicadas a la vez valen menos que cinco buenas que la gente ha leído. Y fusiona si tiene sentido: en una empresa de 38 personas POL-03 puede ser un capítulo de POL-02 y POL-06 puede vivir dentro de POL-04. Lo que no debe fusionarse nunca es lo que tiene destinatarios distintos: POL-08 la lee un proveedor, y no puede recibir el documento interno entero.

Lee el apartado 5.4 con atención: es una lección entera comprimida en cuatro enunciados, y cada uno elimina un fallo concreto de la cronología de 02-06. El 5.4.1 mata la cuenta compartida sin MFA; el 5.4.2, el acceso permanente que existía a las 22:14 de un día cualquiera; el 5.4.3, la ceguera de los 20 días sin detección; y el 5.4.4, el acceso que nadie volvió a mirar. Eso es lo que significa que una política sea trazable a un riesgo.

La Política de Uso Aceptable es la que leen todas las personas de la empresa, incluidas las que no son técnicas, así que su redacción debe ser comprensible sin conocimientos previos. Sus apartados 1 a 3 siguen la plantilla —propósito: proteger a la empresa, a sus clientes y a las propias personas usuarias, tratando R-05 y R-08; alcance: toda persona y todo equipo, cuenta o servicio facilitado por Nimbus, dentro o fuera de la oficina; roles: cada persona responde del uso de sus cuentas, Lucía mantiene la configuración del parque y Marta resuelve las dudas—. Este es su cuerpo:

Dos enunciados merecen comentario porque contradicen el instinto de mucha gente. El 5.3.1 («reportar de más nunca será motivo de reproche») y el cierre del apartado 7 no son buenismo: son diseño de incentivos, porque una política que castiga el clic hace que la gente oculte el clic, y ocultarlo multiplica el tiempo de detección, la variable que más determina el daño (02-06). Y el 5.6.2 existe porque una política que afecta a la privacidad de los empleados sin decir qué se registra y para qué es, además de injusta, jurídicamente frágil.

Nota de validación. Los apartados de uso personal, monitorización, régimen disciplinario y desconexión digital tienen implicaciones laborales y de protección de datos que varían según el convenio y la legislación aplicable, y en muchos casos requieren información previa a la plantilla o consulta a la representación de los trabajadores. Antes de aprobar POL-04, revísala con asesoría laboral y con el responsable de cumplimiento o el delegado de protección de datos. El detalle normativo se trata en 06-03.

Los tres pasos que casi todo el mundo se salta y que deciden si la política sirve. La consulta (3): enseñar el borrador a Lucía, Iván, Rubén y Sara antes de aprobarlo es lo que detecta el enunciado imposible de cumplir; si Rubén dice «con esa regla no puedo atender a un cliente que ha perdido el acceso», hay que arreglarlo antes, no después de que él invente su propio atajo. La comunicación del porqué (6): publicar en una carpeta compartida no es comunicar; la versión que funciona es una reunión de 20 minutos donde se explica qué riesgo trata cada regla, con el caso de 02-06 como argumento. Y la aceptación registrada (7), sin la cual no hay exigibilidad, repetida en cada incorporación y en cada versión mayor.

Un detalle operativo que evita mucho ruido: la política vive en un único sitio con versión visible, porque cuando conviven tres PDF en tres carpetas la que se cumple es la más antigua, que es la que la gente descargó.

Una excepción es el reconocimiento formal de que, en un caso concreto, no se va a cumplir una regla, y es imprescindible que exista: la alternativa a una excepción documentada no es el cumplimiento, es el incumplimiento silencioso. Sus cuatro requisitos innegociables son justificación de negocio, medida compensatoria, aprobación al nivel adecuado y caducidad, siendo esta última la clave, porque una excepción sin fecha de fin es simplemente una política distinta que nadie aprobó.

La segunda entrada es el origen del incidente de 02-06. No hubo una decisión de correr un riesgo: hubo una concesión operativa razonable en 2023 —«dales acceso para que puedan atender de madrugada»— que nadie volvió a mirar, sin compensación, sin aprobador identificable y sin fecha de fin. Compárala con EXC-2026-004: misma excepción sobre el mismo enunciado, pero con cuentas nominales, MFA, grabación de sesión, alerta fuera de ventana, aprobación de la dirección y seis semanas de vigencia. La diferencia no es técnica: es documental, y es exactamente el valor que aporta esta lección.

Cuatro reglas de gestión del registro: revisión mensual de las próximas a caducar; prohibida la renovación automática (renovar exige rehacer la justificación); si una excepción se ha renovado tres veces el problema es la política y hay que cambiarla; y las excepciones abiertas se cuentan como indicador de salud, porque un registro con 30 vigentes describe una política que la organización no puede cumplir.

Y por encima de todas, el criterio que resume la lección: una política que nadie puede cumplir empeora la seguridad. No la deja igual: la empeora, por tres vías. Normaliza el incumplimiento, porque cuando una regla se incumple a diario sin consecuencias todas las demás pierden autoridad. Oculta el riesgo real, porque sobre el papel está tratado y en la práctica no lo está, y el registro de riesgos de 04-01 se vuelve falso. Y destruye la confianza en el sistema documental, de modo que la siguiente política, que quizá sí era importante, nace muerta. Por eso, ante la duda entre un enunciado ambicioso que nadie cumplirá y uno modesto que todo el mundo cumplirá, escribe el modesto y súbelo el año que viene.

Las políticas no se escriben en el vacío: los marcos que viste en 02-01 esperan encontrarlas, y con nombres bastante concretos.

Ese es todo el puente que corresponde a esta lección: el detalle de los marcos y de la certificación es materia de 06-02, y cómo se audita el cumplimiento efectivo, de 06-04.

• Escribir la política antes de tener el registro de riesgos. Sale un documento genérico que no protege nada concreto. Consejo: cada política empieza citando los riesgos que trata; si no puedes citar ninguno, no la escribas todavía. Tampoco metas parámetros técnicos en la política: cada cambio de un número obligaría a reaprobarla, y el «12 caracteres, FIDO2, sesión de 8 horas» vive en la norma.
• Usar «debe» y «debería» al azar. Si todo es «debería», nada es obligatorio; si todo es «debe», la política es incumplible. Consejo: repasa el documento marcando cada verbo normativo y pregúntate si estás dispuesto a auditarlo. Y no apruebes sin consultar a quien la va a cumplir: es la causa número uno de políticas de adorno, y la ronda de consulta dura una semana y ahorra un año de incumplimiento silencioso.
• No tener vía de excepción, o tenerla sin caducidad. Sin excepción formal la gente incumple en silencio; con excepciones sin fecha se reproduce el error que produjo el incidente de 02-06. Consejo: publica el registro de excepciones a la vez que la política, con caduca como campo obligatorio.
• Confundir publicar con comunicar, y no versionar. Una carpeta compartida no forma a nadie, y cuando conviven varias copias se cumple la más antigua. Consejo: 20 minutos explicando el porqué, ubicación única y versión visible en la cabecera.

Clasifica cada enunciado como política, norma, procedimiento o guía, y corrígelo si está mal formulado para su nivel:

1. «Las copias de seguridad se realizarán a las 03:00 mediante el script backup.sh alojado en /opt/nimbus/bin.»
2. «La información de Nimbus debe protegerse conforme a su clasificación durante todo su ciclo de vida.»
3. «Las copias completas se conservarán 90 días y las incrementales 30, con al menos una copia inmutable fuera de la cuenta de producción.»
4. «Es aconsejable revisar el correo de alerta de copias cada mañana antes de empezar.»
5. «Los empleados deberían usar contraseñas de al menos 12 caracteres cuando sea posible.»

El riesgo R-06 del registro de 04-01 dice que un atacante que localice credenciales en texto claro escala a la cuenta cloud A-05. Redacta tres enunciados normativos para POL-07 (Desarrollo Seguro) que traten ese riesgo, en el nivel correcto y con lenguaje normativo. Para cada uno, indica: qué norma o procedimiento lo desarrollaría, qué evidencia demostraría su cumplimiento y una posible excepción legítima con su compensación.

Te presentan esta solicitud:

Identifica todo lo que está mal, decide si la aprobarías y en qué condiciones, y propón una alternativa que resuelva el problema de Iván sin necesitar la excepción.

Ejercicio 1

1. Procedimiento, bien formulado: contiene hora, herramienta y ruta, así que cambia con la infraestructura.
2. Política, correcta: enuncia el qué y el porqué sin parámetros, y sobrevivirá a cualquier cambio técnico.
3. Norma, correcta: números concretos, obligatorios y auditables —se puede comprobar si hay o no una copia inmutable fuera de la cuenta—.
4. Guía («es aconsejable» = no obligatoria). Correcta para su nivel, aunque cabe preguntarse si revisar la alerta de copias no debería ser obligatorio: si lo es, hay que reescribirla como norma con un «DEBE».
5. Mal formulado en dos sentidos: «deberían» y «cuando sea posible» lo hacen no exigible, y a la vez contiene un parámetro (12 caracteres) que pertenece a la norma. Corrección: en la política, «El acceso a los sistemas DEBE autenticarse con credenciales robustas conforme a la Norma de Autenticación»; en la norma, «Longitud mínima 12 caracteres; comprobación obligatoria contra listas de contraseñas filtradas».

Ejercicio 2

Observa que los tres enunciados son de política porque no contienen ningún parámetro que vaya a cambiar con la herramienta —salvo el plazo de 4 horas de 7.3, que es una decisión de riesgo deliberada y por eso se acepta en este nivel—.

Ejercicio 3

Lo que está mal: (a) el solicitante se aprueba a sí mismo, lo que anula la separación de funciones (01-03); (b) no hay compensación; (c) no hay caducidad, con lo que la excepción es permanente por omisión, igual que la de la consultora en 2023; (d) la justificación no acota nada —no dice qué datos, de qué cliente, dónde se copian ni cuándo se destruyen—; (e) no cita el riesgo asociado ni el residual; y (f), lo más grave, es probable que ni siquiera se pueda conceder, porque copiar datos que revelan información de salud a un entorno de desarrollo tiene implicaciones de protección de datos que van más allá de una excepción interna.

¿La aprobarías? No en esa forma. Si no hubiera alternativa, la versión mínima aceptable sería: aprobación de Marta y no de Iván; alcance limitado a un único cliente y con su conocimiento; copia seudonimizada (03-07) y con las notas clínicas suprimidas, no descifradas; entorno aislado con los mismos controles que producción; caducidad de 7 días con borrado verificado; y registro del acceso.

La alternativa que elimina la excepción —y que es la respuesta correcta— es atacar la causa: generar un conjunto de datos sintéticos que reproduzca el volumen y la forma de los reales sin contener ninguno, o un procedimiento de anonimización automática que produzca la copia de preproducción sin datos personales. Cuesta más la primera vez y elimina la excepción para siempre. Recuerda que en el inventario de 01-04 el entorno de preproducción (A-22) figura con clasificación «a revisar» precisamente porque nadie estaba seguro de si contenía datos reales: este ejercicio es esa duda hecha carne.

Has cumplido la promesa que dejó abierta el módulo 3 y que reforzó 04-01: una política es el mecanismo por el que una decisión sobrevive a quien la tomó. Aporta lo que ningún otro artefacto da —persistencia, uniformidad, exigibilidad, delegación y demostrabilidad—, y una regla no escrita ni comunicada no es una regla, sino una preferencia. Dominas la jerarquía documental con precisión: la política dice qué y por qué y la aprueba la dirección; la norma dice qué es obligatorio y medible, y ahí van los parámetros; el procedimiento dice cómo, paso a paso, y cambia con la herramienta; la guía recomienda y no obliga. Lo has visto recorrer un mismo tema —contraseñas y MFA— por los cuatro niveles, con la tabla que explica la razón práctica de todo el sistema: cada nivel cambia con su propia frecuencia y lo aprueba quien corresponde.

Tienes la anatomía completa de una política y su plantilla reutilizable, con los tres apartados que todo el mundo omite: el propósito trazado al riesgo, lo que queda expresamente fuera del alcance y la vía de excepción. Tienes el conjunto mínimo de once políticas para una PYME con su orden de prioridad derivado del registro de riesgos, y dos de ellas redactadas enteras: la Política de Control de Accesos, cuyo apartado 5.4 mata uno por uno los cuatro fallos del acceso de la consultora en 02-06, y la Política de Uso Aceptable, donde el diseño de incentivos —reportar nunca se reprocha, ocultar sí— importa tanto como las reglas.

Conoces el ciclo de vida de una política con los tres pasos que deciden si sirve: la consulta previa que detecta lo imposible de cumplir, la comunicación del porqué que no es publicar en una carpeta, y la aceptación registrada sin la cual no hay exigibilidad. Y te llevas el artefacto que más daño evita: el registro de excepciones, con sus cuatro requisitos innegociables —justificación, compensación, aprobación al nivel adecuado y caducidad—, ilustrado con la comparación entre una excepción bien hecha de seis semanas y la excepción sin fecha de 2023 que es el origen del incidente de 02-06. Cierra la lección el criterio que la resume: una política que nadie puede cumplir empeora la seguridad, porque normaliza el incumplimiento, oculta el riesgo real y deja muerta a la siguiente política antes de nacer.

Pero fíjate en lo que has escrito. POL-02 dice que el acceso de terceros «debe ser nominal, con MFA y just-in-time»; POL-04 dice que los equipos «deben mantener activo el cifrado de disco». Eso son declaraciones de intención hasta que algo las hace ciertas: alguien tiene que configurar el MFA, verificar que los 40 portátiles están cifrados de verdad, comprobarlo periódicamente y dejar evidencia de que lo comprobó. Ese «algo» tiene nombre y es el tercer vértice del triángulo. En la siguiente lección, Controles de Seguridad (04-03), cerrarás el triángulo riesgo → política → control: las dos clasificaciones que hay que dominar —por naturaleza y por función—, por qué todo riesgo relevante necesita controles de más de una función, los catálogos de referencia CIS v8 e ISO 27002, cómo se selecciona un control contando su carga operativa recurrente, el catálogo de controles de Nimbus como artefacto, la diferencia entre un control implantado y un control eficaz, las métricas que lo miden y la matriz de trazabilidad que salva una auditoría.