Controles organizativos ISO 27001: políticas, roles y gobernanza

Cuando un equipo técnico piensa en la ISO 27001, imagina cifrado, control de accesos y firewalls. Pero la mayor parte del Anexo A no habla de tecnología: habla de cómo se gobierna la seguridad. Los 37 controles organizativos son el esqueleto del SGSI —políticas, roles, proveedores, incidentes, cumplimiento— y son, estadísticamente, donde más no conformidades aparecen en las auditorías de certificación. No porque sean difíciles, sino porque se dejan para el final y se resuelven con plantillas que nadie se cree.

Este es el tercer capítulo de nuestra guía completa de certificación ISO 27001. En él desmontamos el mito de la burocracia: verás qué exige realmente cada bloque organizativo, cómo documentarlo con mentalidad de ingeniero y cómo repartir responsabilidades en empresas que no tienen (ni necesitan) un departamento de seguridad.

1. El Anexo A 2022: dónde encajan los controles organizativos

La versión 2022 de la norma reorganizó los antiguos 14 dominios en 4 temas: controles organizativos (37), de personas (8), físicos (14) y tecnológicos (34). En este capítulo cubrimos los dos primeros —la gobernanza y el factor humano—, que juntos suman casi la mitad del catálogo.

Recuerda la regla de oro que vimos en el capítulo de análisis de riesgos: ningún control se implanta «porque lo dice el Anexo A», sino porque responde a un riesgo identificado. La Declaración de Aplicabilidad es el puente: cada control organizativo que actives debe poder responder a la pregunta del auditor «¿qué riesgo trata esto?».

2. Políticas de seguridad: pocas, cortas y de verdad

El control 5.1 pide una política de seguridad de la información aprobada por dirección, comunicada a todo el personal y revisada periódicamente. De ella cuelgan políticas temáticas específicas según tu contexto: control de accesos, clasificación de la información, uso aceptable, teletrabajo, desarrollo seguro, proveedores, incidentes…

La estructura documental sana tiene tres niveles:

• Política marco (1-3 páginas): principios, compromiso de dirección, ámbito y responsabilidades generales. Es el documento que firma el CEO.
• Políticas temáticas (1-2 páginas cada una): reglas concretas por área. «Todo acceso administrativo requiere MFA», «la información se clasifica en 3 niveles», «los portátiles cifran disco completo».
• Procedimientos e instrucciones: el paso a paso operativo — cómo dar de alta un usuario, cómo responder a un incidente, cómo desplegar a producción.

Errores a evitar: políticas de 40 páginas descargadas de internet (el auditor las reconoce y el equipo las ignora), políticas que prometen lo que no haces («análisis forense en 4 horas» sin nadie de guardia) y políticas sin dueño ni fecha de revisión. La recomendación práctica que damos siempre: gestiona las políticas como código —repositorio, versiones, pull requests para cambios y revisión anual programada—. Para un equipo de desarrollo es natural y genera el historial de revisiones que la norma exige.

2.1 Qué políticas temáticas necesitas realmente

Depende de tu contexto y de tu SoA, pero para una empresa que desarrolla u opera plataformas web el conjunto típico es: control de accesos (quién accede a qué y cómo se autoriza), uso aceptable y puesto de trabajo (equipos, teletrabajo, BYOD si aplica), clasificación y manejo de la información, desarrollo seguro (revisión de código, gestión de dependencias, separación de entornos — la ampliaremos en el capítulo de controles técnicos), relación con proveedores, gestión de incidentes, continuidad y backups y criptografía (qué se cifra y con qué estándares). Ocho documentos cortos. Si alguna no trata ningún riesgo tuyo, no la escribas: la SoA justifica exclusiones.

3. Roles y responsabilidades: quién manda en qué

El control 5.2 exige roles y responsabilidades de seguridad definidos y asignados; el 5.3, segregación de funciones donde el riesgo lo requiera. En una gran empresa esto significa CISO, comité de seguridad y matriz RACI. En una pyme tecnológica, la versión proporcional funciona así:

• Responsable de seguridad (rol, no puesto): normalmente el CTO o un lead senior con el 20-30% de dedicación. Coordina el SGSI, reporta a dirección y es el interlocutor en auditorías.
• Dirección: aprueba la política y el apetito de riesgo, dota recursos y revisa el sistema formalmente al menos una vez al año.
• Propietarios de activos y riesgos: cada sistema o dato relevante tiene un responsable de negocio que decide sobre él.
• Todo el equipo: cumple las políticas y reporta incidentes. La seguridad no se delega entera en el rol de seguridad.

Sobre la segregación con equipos pequeños: cuando la misma persona desarrolla y despliega, compensa con controles alternativos —revisión de código obligatoria por un segundo par de ojos, aprobaciones de despliegue, logs inmutables— y documenta esa decisión. La norma acepta la proporcionalidad; lo que no acepta es la ausencia de reflexión. Este espíritu lo cuentan muy bien quienes han pasado del ataque a la defensa, como vimos en de hacker a ciberseguridad corporativa: los atacantes explotan precisamente los huecos de responsabilidad que nadie reclama.

4. Seguridad en las personas: del alta a la baja

Los 8 controles de personas cubren el ciclo completo de la relación laboral:

• Antes de contratar: verificación de antecedentes proporcional al puesto (referencias, titulación) y cláusulas de confidencialidad en contratos.
• Durante: formación y concienciación periódica —phishing simulado, buenas prácticas, novedades de las políticas—, proceso disciplinario definido y canales claros para reportar incidentes sin miedo.
• Al salir: el punto débil clásico. Checklist de baja ejecutable en horas: revocar accesos (SSO ayuda muchísimo), recuperar equipos, recordar obligaciones de confidencialidad post-contrato.

La evidencia que pide el auditor es sencilla de generar si el proceso existe: registros de formación con asistentes y fecha, el checklist de baja firmado del último empleado que se fue, el contrato tipo con su cláusula. Si tienes que fabricarlo la semana antes de la auditoría, el problema no es documental.

Un apunte de cultura que marca la diferencia: la concienciación funciona cuando se adapta a la audiencia. A un equipo de desarrollo no le cuentes qué es el phishing; enséñale casos de typosquatting en npm, tokens filtrados en repositorios públicos o ingeniería social dirigida a devops. El interés se multiplica y el mensaje cala, porque conecta con su trabajo diario. La formación genérica de compliance es la que genera la fama de «papeleo» que arrastra la norma.

5. Gestión y clasificación de activos de información

Tres controles encadenados: inventario de activos (5.9), uso aceptable (5.10) y devolución (5.11), más la clasificación de la información (5.12-5.13). El inventario ya lo construiste en el análisis de riesgos; aquí se trata de mantenerlo vivo y de etiquetar la información según su sensibilidad.

Para la clasificación, tres niveles bastan en la mayoría de empresas: pública (web, material comercial), interna (documentación de proyectos, código) y confidencial (datos personales, credenciales, información de clientes bajo NDA). Lo importante no es la etiqueta sino las reglas asociadas: dónde puede almacenarse cada nivel, quién puede acceder, cómo se comparte con terceros y cuándo se destruye. Una tabla de una página resuelve el 90% de las dudas del equipo.

6. Proveedores: el riesgo que entra por contrato

Los controles 5.19 a 5.23 obligan a gestionar la seguridad en las relaciones con proveedores: identificar cuáles tocan tu información, exigirles requisitos proporcionales, incluirlos en contratos y revisar su cumplimiento. Con el ecosistema actual —hosting, SaaS, pasarelas, APIs, freelancers— este bloque ha pasado de trámite a crítico: buena parte de las brechas serias de los últimos años entraron por la cadena de suministro.

Versión práctica para una pyme: mantén un registro de proveedores con acceso a información (del cloud principal al freelance puntual), clasifícalos por criticidad, y para los críticos verifica certificaciones (ISO 27001, SOC 2), firma DPAs cuando haya datos personales y define qué pasa si tienen un incidente. Para el resto, condiciones estándar y sentido común. Y añade el disparador al proceso de compras: proveedor nuevo con acceso a datos → pasa por el registro antes de firmar.

7. Gestión de incidentes: cuando algo falla (y fallará)

Los controles 5.24 a 5.28 piden un proceso de gestión de incidentes: cómo se reporta, quién evalúa, cómo se responde, qué se aprende y qué evidencias se conservan. No necesitas un SOC 24/7; necesitas que cualquier persona del equipo sepa a quién avisar un domingo por la noche y que exista un playbook básico para los escenarios probables: ransomware, compromiso de cuenta, fuga de datos, caída de proveedor.

Elemento legal que no puede faltar en España y la UE: el circuito de notificación. Brecha con datos personales → evaluación y, si procede, notificación a la AEPD en 72 horas; clientes afectados según contratos. Definirlo en frío cuesta una tarde; improvisarlo en caliente cuesta multas y clientes. Y cada incidente real alimenta el registro de lecciones aprendidas que retro-alimenta el análisis de riesgos — el ciclo de mejora continua funcionando.

8. Cumplimiento y contacto con autoridades

Cierra el bloque organizativo el cumplimiento legal (5.31-5.37): identificar la legislación aplicable (RGPD/LOPDGDD, propiedad intelectual, requisitos contractuales de clientes, y sectoriales como NIS2 si te aplica), proteger los registros que la evidencian y mantener contacto con autoridades y grupos de interés (AEPD, INCIBE-CERT). Una tabla de requisitos legales con su responsable y evidencia asociada, revisada anualmente, cubre el control con solvencia.

9. El kit documental mínimo del bloque organizativo

Para aterrizar todo lo anterior, este es el conjunto de documentos organizativos con el que una empresa tecnológica de 10-100 empleados supera con solvencia una certificación (y, sobre todo, gestiona de verdad):

• Política de seguridad de la información (marco, firmada por dirección) — 2 páginas.
• Políticas temáticas: control de accesos, uso aceptable y teletrabajo, clasificación de la información, desarrollo seguro, proveedores, incidentes, continuidad — 1-2 páginas cada una.
• Registro de roles y responsabilidades — 1 página con el reparto real.
• Inventario de activos + registro de riesgos + SoA — heredados del análisis de riesgos.
• Registro de proveedores con criticidad y verificaciones.
• Procedimiento y registro de incidentes con el circuito de notificación (AEPD 72h).
• Checklists de alta/baja de personal y registros de formación.
• Tabla de requisitos legales y calendario de revisiones (accesos, políticas, dirección).

Quince documentos vivos, ninguno de más de tres páginas. Ese es el volumen real de la «burocracia» ISO cuando se hace con criterio.

10. Errores típicos del bloque organizativo en auditoría

• La política fantasma. Existe, está firmada… y nadie del equipo sabe que existe. Primera pregunta del auditor a cualquier empleado: «¿conoces la política de seguridad? ¿dónde está?». Comunicación y formación son parte del control, no un extra.
• Roles en papel que no coinciden con la realidad. El documento dice que el «Comité de Seguridad» se reúne mensualmente; las actas dicen que se reunió una vez hace un año. Ajusta el papel a tu realidad, no al revés.
• El proveedor crítico sin contrato. La agencia que administra tu servidor con acceso root y un acuerdo verbal de 2019. Es de las no conformidades más repetidas y de las más fáciles de prevenir.
• Incidentes sin registro. «¿Habéis tenido incidentes este año?» — «Alguno hubo…» Sin registro no hay gestión, y decir «cero incidentes» en 12 meses tampoco cuela: indica que nadie reporta.
• Bajas con accesos vivos. El auditor pide la lista de bajas del año y comprueba dos o tres cuentas al azar. Si el exempleado de marzo sigue teniendo acceso al CRM, tienes una no conformidad y un riesgo real.
• Formación de un solo uso. Una charla en el onboarding de 2023 no es «concienciación periódica». Algo tan ligero como una píldora trimestral + simulacro de phishing anual cumple y funciona.

11. Documentar sin burocracia: el método

La queja universal —»la ISO es papeleo»— tiene antídoto conocido:

• Documenta lo que haces, no lo que suena bien. Si el procedimiento dice «revisión trimestral de accesos», agenda la revisión trimestral. La coherencia papel-realidad es lo primero que testea el auditor entrevistando al equipo.
• Formato mínimo viable: una política de una página que se cumple vale más que un manual que no. Usa las herramientas del equipo: Git, Notion, Drive versionado.
• Evidencias automáticas: diseña los procesos para que dejen rastro solos — el alta de usuario por ticket, la formación con registro de asistencia, la revisión de accesos como issue recurrente con checklist.
• Un dueño por documento y fecha de próxima revisión. Documento sin dueño = documento muerto.

12. Las preguntas que hará el auditor (literalmente)

Para que prepares al equipo, estas son preguntas reales del bloque organizativo en auditorías de fase 2, con lo que el auditor busca en cada una:

• «Enséñame la última revisión de la política de accesos y quién la aprobó.» — Busca el ciclo de vida documental: versión, fecha, aprobador.
• «¿Quién es el propietario de la base de datos de clientes? ¿Qué decide?» — Busca que los propietarios de activos existan más allá del papel.
• «Un desarrollador dejó la empresa en marzo. Muéstrame su baja.» — Busca el checklist ejecutado y las cuentas revocadas. Suele comprobarlo en vivo contra el SSO.
• «¿Cuál fue vuestro último incidente y qué aprendisteis?» — Busca el registro, la respuesta según procedimiento y la lección incorporada. «No hemos tenido ninguno» es mala respuesta.
• «Este proveedor aloja vuestra plataforma. ¿Qué garantías de seguridad os da?» — Busca el contrato, el DPA y la verificación de certificados.
• «¿Cuándo fue la última formación de seguridad y quién asistió?» — Busca el registro con fechas y asistentes.
• (A cualquier empleado, sin el responsable delante:) «Si detectas algo raro en tu equipo, ¿qué haces?» — Busca que el canal de reporte sea conocido de verdad.

Fíjate en el patrón: ninguna pregunta es teórica. Todas piden evidencia o comportamiento real. Por eso la preparación correcta no es memorizar documentos, sino haber operado el sistema unos meses. Es la misma filosofía que aplicamos al hacking ético: la seguridad se demuestra en la práctica, no en la declaración.

Conclusión: gobernanza que aguanta una auditoría (y un incidente)

Los controles organizativos son la diferencia entre tener herramientas de seguridad y tener seguridad gestionada. Políticas cortas y reales, roles claros aunque compartidos, personas formadas, proveedores contractualizados y un proceso de incidentes ensayado: eso es lo que el auditor quiere ver, y —más importante— lo que sostiene a tu empresa el día que algo falla.

Y un último apunte estratégico: este bloque es el más reutilizable de toda la norma. Las mismas políticas, roles y procesos te servirán casi sin cambios si más adelante abordas el Esquema Nacional de Seguridad, SOC 2 o los requisitos de seguridad de NIS2. Cada hora invertida en gobernanza bien hecha se amortiza varias veces.

En el próximo capítulo bajamos al terreno favorito de los equipos técnicos: los controles tecnológicos y el desarrollo seguro. Y si te incorporas ahora a la serie, empieza por la guía completa de certificación ISO 27001.