Uno de los tropiezos más recurrentes al implementar un Sistema de Gestión de Seguridad de la Información (SGSI) consiste en reducir la documentación a un trámite puramente formal: descargar plantillas genéricas, cambiar logotipos y acumular documentos en una carpeta compartida que nadie lee.
Bajo la norma vigente ISO/IEC 27001:2022 (y su correspondiente actualización contextual mediante ISO/IEC 27001:2022/Amd 1:2024), las políticas no son manuales de software ni listas estáticas de prohibiciones. Son el instrumento mediante el cual la dirección establece sus intenciones estratégicas, define límites operativos claros y proporciona la base para mitigar riesgos reales de negocio. Para comprender la estructura global del estándar, te sugerimos consultar nuestra guía completa de ISO 27001.
La cadena de valor documental en ISO 27001
Contexto y Riesgo → Decisión Directiva → Política Marco → Objetivos de Seguridad → Políticas Temáticas → Procedimientos Operativos → Evidencias Demostrables
El propósito de este artículo es guiarte en el paso crítico desde el requisito abstracto de la norma hasta la construcción de una arquitectura documental sostenible, modular y verdaderamente defendible ante cualquier auditoría técnica.
Del requisito general al marco integral de políticas
Cuando una organización se plantea formalizar la seguridad de la información, suele preguntarse: ¿Basta con redactar una única política de seguridad o debemos redactar decenas de documentos independientes?
La respuesta radica en entender la diferencia entre un principio directivo y una regla temática de control. Una única política de alto nivel es imprescindible para comprometer a la alta dirección y establecer el marco de gobernanza, pero resulta insuficiente para regular aspectos específicos como la gestión de credenciales, el cifrado de datos o las relaciones con proveedores en la nube.
Por el contrario, generar 40 documentos independientes sin un marco estructurado suele derivar en lo que se conoce como hipertrofia documental: textos contradictorios entre sí, revisiones desactualizadas y un equipo técnico desorientado. Para evitar este problema, es fundamental delimitar previamente qué es un SGSI y cómo definir su alcance, asegurando que cada documento responda a límites operativos bien definidos.
Un marco de políticas de seguridad es un ecosistema organizado de directrices que traduce la estrategia corporativa en mandatos concretos. No debe concebirse como un fin en sí mismo, sino como el puente que conecta el apetito de riesgo de la organización con la operativa técnica cotidiana.
Requisitos normativos: Cláusula 5.2 frente al Anexo A
Para diseñar un marco riguroso, es imprescindible distinguir qué exige la norma como requisito mandatorio del sistema de gestión y qué ofrece como catálogo de controles orientativos.
En ISO/IEC 27001:2022 existen dos anclajes normativos principales respecto a las políticas:
- Cláusula 5.2 (Política de la seguridad de la información): Es un requisito obligatorio del cuerpo principal de la norma (cláusulas 4 a 10). Exige que la alta dirección establezca, mantenga e implemente una política de seguridad que sea apropiada al propósito de la organización, proporcione un marco de referencia para fijar los objetivos de seguridad, contenga el compromiso expreso de cumplir los requisitos aplicables (legales, contractuales y reglamentarios) y asuma el compromiso de mejora continua del SGSI. Además, debe mantenerse como información documentada, comunicarse dentro de la empresa y estar disponible para las partes interesadas según corresponda.
- Anexo A — Control 5.1 (Políticas para la seguridad de la información): Es un control perteneciente a los Controles Organizacionales del Anexo A. Requiere que tanto la política general como las políticas temáticas específicas sean formalmente definidas, aprobadas por la dirección, publicadas, comunicadas al personal y a las partes interesadas pertinentes, y revisadas a intervalos planificados o cuando surjan cambios significativos.
Esta distinción es capital: mientras que la Cláusula 5.2 regula la política paraguas institucional respaldada por el liderazgo y compromiso de la dirección, el Control A.5.1 exige la existencia, gobernanza y mantenimiento activo del conjunto de políticas temáticas que sustentan los controles operativos. Si deseas profundizar en la redacción específica de la directriz corporativa, revisa nuestro análisis sobre la política de seguridad de la información en la cláusula 5.2.
Asimismo, el marco de políticas se conecta de manera directa con las demás cláusulas del estándar:
- Contexto y partes interesadas (4.1 y 4.2): Determina qué obligaciones externas y expectativas de negocio condicionan las reglas internas.
- Planificación y riesgos (6.1): Las políticas nacen de las decisiones tomadas tras la evaluación del riesgo; cada regla obligatoria debe mitigar un escenario de riesgo identificado.
- Objetivos de seguridad (6.2): La política establece los principios rectores que permiten fijar objetivos de seguridad medibles y evaluables.
- Toma de conciencia y comunicación (7.3 y 7.4): Una política no aprobada ni comunicada carece de validez ante un auditor y ante los propios colaboradores.
- Información documentada (7.5): Dicta las reglas de control de versiones, confidencialidad, aprobación y retención documental.
- Revisión por la dirección (9.3) y Mejora continua (10): Garantiza que el marco se revise formalmente al menos una vez al año y se adapte ante incidentes o transformaciones tecnológicas.
Jerarquía documental: políticas, estándares, procedimientos y registros
Uno de los errores más dañinos en proyectos de certificación es utilizar los términos política, procedimiento y estándar como si fueran sinónimos intercambiables. No lo son. Cada nivel documental cumple una misión específica en la pirámide de gobernanza.
Presentamos a continuación una arquitectura conceptual de cinco niveles, ampliamente reconocida como la mejor práctica en la industria para organizar la información documentada sin generar fricción operativa:
↓
NIVEL 2: POLÍTICAS TEMÁTICAS Y ESTÁNDARES (Reglas obligatorias y líneas base técnicas)
↓
NIVEL 3: PROCEDIMIENTOS OPERATIVOS (Pasos cronológicos: quién, cómo y cuándo)
↓
NIVEL 4: GUÍAS E INSTRUCCIONES DE TRABAJO (Detalles de soporte y recomendaciones)
↓
NIVEL 5: REGISTROS Y EVIDENCIAS (Pruebas objetivas de ejecución y cumplimiento)
Es crucial aclarar que ISO/IEC 27001 no impone textualmente esta jerarquía piramidal ni obliga a usar esta nomenclatura exacta. La norma emplea el término genérico y flexible de información documentada (cláusula 7.5 de ISO 27001). No obstante, diferenciar estos niveles resulta indispensable en la práctica para que la documentación sea gobernable y fácil de auditar.
| Nivel Documental | Pregunta que responde | Grado de detalle | Audiencia principal | Frecuencia de cambio | Nivel de aprobación |
|---|---|---|---|---|---|
| Política General | ¿Por qué y hacia dónde vamos? | Estratégico / Alto nivel | Toda la organización y terceros | Baja (1 a 3 años) | Alta Dirección (CEO / Consejo) |
| Políticas Temáticas | ¿Qué se exige y qué se prohíbe? | Táctico / Directriz normativa | Departamentos y usuarios clave | Media (anual) | CISO / Comité de Seguridad |
| Estándares Técnicos | ¿Qué especificación exacta se aplica? | Técnico / Línea base (Baseline) | Ingenieros, DevOps, SysAdmins | Media-Alta (semestral/anual) | Responsable Técnico / CISO |
| Procedimientos | ¿Quién hace qué, cómo y en qué orden? | Operativo / Flujo paso a paso | Operadores y ejecutores del proceso | Alta (ante cambios de herramientas) | Dueño del Proceso / Responsable IT |
| Guías / Instrucciones | ¿Cómo se utiliza una herramienta concreta? | Manual práctico / Tutorial | Usuarios finales o administradores | Alta (asociada al software) | Equipo técnico / Soporte |
| Registros / Evidencias | ¿Qué se hizo realmente y cuándo? | Evidencia fáctica e inmutable | Auditores y supervisores | Continuo (tiempo real) | Firmas, logs o tickets automáticos |
Observa la diferencia con un ejemplo cotidiano:
- Política temática: «Todos los accesos remotos a la red corporativa deben autenticarse mediante factores múltiples de verificación (MFA)». (Establece el mandato obligatorio sin casarse con una tecnología).
- Estándar técnico: «El algoritmo TOTP debe operar bajo RFC 6238 con claves de 6 dígitos y ventana de 30 segundos, o mediante llaves FIDO2/WebAuthn». (Define la especificación técnica).
- Procedimiento: «1. El usuario solicita acceso por ServiceNow. 2. El responsable valida el rol. 3. IT enrola el dispositivo en la plataforma de identidades y envía el QR cifrado». (Describe la secuencia de pasos).
- Registro: El log de autenticación exitosa en el proveedor de identidades que demuestra que el usuario
m.garciainició sesión con MFA el 20 de septiembre a las 09:14 CEST.
El Control A.5.1 y la orientación de ISO/IEC 27002:2022
En la versión 2022 de la norma, los controles del Anexo A se reestructuraron radicalmente: pasaron de las 14 cláusulas de 2013 a 4 dominios temáticos que suman 93 controles. Para comprender el funcionamiento integral de este catálogo, consulta nuestra guía sobre los controles organizacionales de ISO 27001.
El primer control del catálogo, el Control A.5.1 (Políticas para la seguridad de la información), establece las condiciones de gobernanza para todo el corpus documental. Mientras ISO/IEC 27001:2022 fija el requisito sintético, el estándar de buenas prácticas ISO/IEC 27002:2022 detalla cómo implementarlo de forma efectiva. Si tienes dudas sobre cómo se complementan ambos textos, puedes leer nuestra comparativa entre ISO 27001 y ISO 27002 y nuestra guía de controles ISO 27002.
Atributos del Control 5.1 según ISO/IEC 27002:2022
Tipo de control: Preventivo.
Propiedades de seguridad: Confidencialidad, Integridad y Disponibilidad.
Conceptos de ciberseguridad: Identificar y Gobernar (Identify, Govern).
Capacidad operativa: Gobernanza de la seguridad de la información.
Dominio de seguridad: Gobernanza y ecosistema.
La orientación práctica de ISO/IEC 27002:2022 para este control destaca seis aspectos críticos que todo responsable de seguridad debe implementar:
- Definición estructurada: Las políticas deben redactarse en función de las necesidades de negocio, los requisitos legales y regulatorios, y los resultados de la gestión de riesgos.
- Aprobación formal por nivel directivo adecuado: Una política redactada por el equipo técnico pero no firmada formalmente por la dirección carece de fuerza de obligado cumplimiento.
- Publicación y accesibilidad: Los documentos deben almacenarse en repositorios conocidos y fácilmente accesibles para los empleados y partes interesadas autorizadas (intranet, portal del empleado, gestor documental).
- Comunicación y comprensión activa: No es suficiente publicar un archivo; es obligatorio comunicarlo activamente mediante planes de sensibilización, onboarding y capacitaciones periódicas.
- Revisión periódica planificada: Deben revisarse a intervalos regulares (al menos una vez al año) o de forma inmediata ante eventos desencadenantes: cambios organizativos mayores, incidentes de seguridad graves, modificaciones tecnológicas o novedades normativas.
- Asignación de propietarios (Policy Owners): Cada documento debe contar con un responsable asignado encargado de velar por su exactitud, pertinencia y ciclo de vida.
Arquitectura práctica: política corporativa y políticas temáticas
¿Cómo aterrizar todo esto en un catálogo real de documentos? A continuación, planteamos un modelo representativo de arquitectura documental moderna para un SGSI maduro:
Nivel 1: Política Corporativa de Seguridad de la Información
Obligatoria · Cláusula 5.2Documento paraguas institucional (2 a 4 páginas). Establece el compromiso de la dirección, los objetivos de alto nivel, la estructura de responsabilidades del SGSI, el deber de cumplimiento y las directrices de mejora continua. Aprobada directamente por el Comité Ejecutivo o el Director General.
Nivel 2: Biblioteca de Políticas Temáticas (Topic-Specific Policies)
Orientación Anexo A / ISO 27002Conjunto modular de directrices orientadas a dominios de riesgo específicos. En una organización mediana o grande, suelen estructurarse en los siguientes bloques:
Aclaración fundamental sobre modularidad: ISO/IEC 27001 no exige que cada uno de estos temas constituya un documento PDF independiente con portada propia. Una pyme o una empresa tecnológica de 30 personas puede consolidar estos requisitos en un Manual de Políticas de Seguridad estructurado en 4 capítulos coherentes (ej. Personas, Accesos y Datos, Operaciones Técnicas, Terceros). Lo que la norma audita no es la cantidad de archivos físicos, sino que los temas pertinentes estén cubiertos, aprobados y vigentes.
Políticas basadas en el riesgo, contexto y cambio climático (Amd 1:2024)
Un error recurrente al redactar políticas es abordarlas como normas genéricas de convivencia digital, desvinculadas de la operativa real del negocio. El estándar exige exactamente lo contrario: el marco debe emanar del análisis del contexto organizativo y de la evaluación sistemática de riesgos y oportunidades.
La regla de diseño es unívoca:
RIESGO REAL IDENTIFICADO → DECISIÓN ESTRATÉGICA → POLÍTICA TEMÁTICA → PROCEDIMIENTO OPERATIVO → EVIDENCIA OBJETIVA
Analicemos cómo cambia drásticamente la prioridad de las políticas según el perfil organizativo:
- Empresa SaaS nativa cloud y remota (50 empleados): Su riesgo crítico radica en la fuga de datos de clientes, el compromiso de credenciales y los fallos en pipelines CI/CD. Sus políticas temáticas prioritarias serán: gestión de identidades y MFA obligatorio, desarrollo seguro (DevSecOps), cifrado de bases de datos multi-tenant y homologación de proveedores cloud. La seguridad física de sedes ocupará un rol secundario o testimonial.
- Hospital o centro sanitario: La prioridad absoluta es la confidencialidad de historias clínicas (datos de categoría especial bajo RGPD) y la disponibilidad 24/7 de sistemas de soporte vital. Su marco exigirá políticas estrictas de segregación de redes médicas (IoMT), accesos de emergencia debidamente auditados (mecanismos break-glass para personal de guardia) y políticas de copias de seguridad inmutables frente al ransomware.
- Entidad bancaria o aseguradora: El foco rector se centra en la prevención de fraude, la integridad de transacciones y el estricto cumplimiento regulatorio (DORA, NIS2). Exigirá políticas de segregación de funciones (SoD), doble control operativo (regla de los 4 ojos) y monitorización continua de transacciones privilegiadas.
- Industria manufacturera (entornos OT/SCADA): Su máxima prioridad es la continuidad de las líneas de ensamblaje y la seguridad de los trabajadores. Su marco priorizará la segmentación entre redes IT y OT, el control de acceso físico a plantas y políticas de parcheo que no interrumpan la producción.
Incorporación de ISO/IEC 27001:2022/Amd 1:2024: Cláusulas 4.1 y 4.2
En febrero de 2024, ISO publicó la Enmienda 1 (Amd 1:2024) para todas las normas de sistemas de gestión armonizadas, incluyendo ISO/IEC 27001:2022. Esta enmienda introduce dos obligaciones precisas:
- Cláusula 4.1: La organización debe determinar si el cambio climático es una cuestión relevante para su contexto.
- Cláusula 4.2: La organización debe determinar si las partes interesadas pertinentes tienen requisitos relacionados con el cambio climático.
Es vital comprender el alcance exacto de esta enmienda: no obliga a redactar una «política climática de seguridad de la información» independiente. Pretender inventar ese documento generaría una no conformidad por falta de comprensión de la norma.
Su aplicación práctica en el marco de políticas consiste en valorar si los fenómenos climáticos extremos (olas de calor que degraden la refrigeración de centros de datos, inundaciones que afecten a instalaciones físicas o caídas prolongadas de suministro eléctrico) constituyen amenazas sobre los activos de información. Cuando estas amenazas sean relevantes, deben reflejarse de forma coherente en las políticas temáticas de continuidad tecnológica y en los criterios de homologación de centros de datos y proveedores de nube en el plan de tratamiento de riesgos.
Metodología paso a paso: cómo redactar, aprobar y desplegar una política
Diseñar una política no consiste en redactar un borrador rápido y remitirlo por correo. Requiere un proceso estructurado que garantice su legitimidad, viabilidad y aplicabilidad técnica:
- Identificar el propósito y el detonante: Definir qué necesidad justifica el documento (un nuevo requisito regulatorio como NIS2, un riesgo identificado en el análisis de riesgos o la adopción de una nueva tecnología como contenedores o IA).
- Delimitar el alcance específico: Acotar con exactitud a qué personas, aplicaciones, filiales, redes y tipos de datos vincula la política. Las exclusiones injustificadas son focos de no conformidad.
- Nombrar un propietario del documento (Policy Owner): Designar a una persona con competencia y autoridad (por ejemplo, el CISO para políticas generales, o el Director de RRHH para políticas vinculadas a empleados).
- Mapear requisitos legales, contractuales y de control: Identificar qué artículos de leyes de privacidad, contratos con clientes o controles del Anexo A deben satisfacerse obligatoriamente.
- Redactar directrices claras en lenguaje mandatorio: Las políticas deben utilizar un lenguaje preciso («debe», «no está permitido») y evitar expresiones ambiguas («se recomienda», «en la medida de lo posible»). Deben fijar el qué, dejando el cómo técnico para los procedimientos.
- Asignar roles y responsabilidades: Detallar quién debe aplicar la regla, quién debe auditar su cumplimiento y quién debe reportar los incidentes derivados.
- Definir el régimen formal de excepciones: Una política sin proceso formal de excepciones es una política que fomenta el incumplimiento silencioso. Se debe regular quién puede solicitar una excepción, qué justificación técnica se exige, quién la aprueba y cuál es su vigencia máxima.
- Aprobación formal por la dirección competente: Someter el documento final a la aprobación expresa del órgano de gobierno o responsable con autoridad delegada. Debe existir constancia fechada y firmada.
- Comunicación activa y plan de formación: Publicar el documento en el repositorio oficial y desplegar sesiones de capacitación o avisos formales dirigidos a las audiencias afectadas.
- Implementación de controles técnicos y registro de evidencias: Habilitar los controles tecnológicos que refuercen la política (por ejemplo, directivas de grupo GPO, políticas de acceso condicional o bloqueo DLP) para no depender únicamente de la buena voluntad del usuario.
- Revisión periódica planificada: Establecer una fecha de próxima revisión (habitualmente 12 meses) y registrar las conclusiones en actas de seguimiento.
- Actualización ante cambios significativos: Disparar revisiones extraordinarias tras incidentes graves de seguridad, reorganizaciones internas o migraciones tecnológicas.
Anatomía recomendada de un documento de política
- Metadatos de control: Código interno, título, versión, fecha de aprobación, fecha de entrada en vigor, fecha de próxima revisión, propietario y aprobador.
- 1. Propósito y objetivos: Por qué existe el documento y qué riesgos busca mitigar.
- 2. Alcance: Personal, activos e infraestructuras a los que aplica.
- 3. Roles y responsabilidades: Obligaciones de usuarios, custodios técnicos, propietarios de activos y responsables de seguridad.
- 4. Principios y reglas mandatorias: Directrices operativas de obligado cumplimiento.
- 5. Gestión de excepciones: Procedimiento para autorizar desviaciones temporales debidamente justificadas.
- 6. Cumplimiento y régimen disciplinario: Supervisión del cumplimiento y consecuencias del incumplimiento doloso o negligente.
- 7. Documentación relacionada: Referencias a estándares, procedimientos operativos y registros vinculados.
- 8. Historial de versiones: Tabla con número de versión, autor, fecha y resumen sintético de cambios.
Ejemplo práctico desglosado: política de control de acceso
Para ilustrar cómo se estructura un documento temático sin caer en el exceso de detalles de configuración, analizamos a continuación un modelo extractado de Política Temática de Control de Acceso e Identidades:
CÓDIGO: POL-SEC-03 · POLÍTICA TEMÁTICA DE CONTROL DE ACCESO E IDENTIDADES
Versión 2.1 · Vigente1. Propósito: Establecer las directrices de seguridad para garantizar que el acceso a los sistemas de información, redes corporativas y datos de la organización se conceda de manera controlada, justificada y restringida exclusivamente a usuarios debidamente autorizados, mitigando el riesgo de accesos no autorizados, fuga de información y abuso de privilegios.
2. Alcance: Aplica a la totalidad de empleados, colaboradores externos, contratistas y proveedores que interactúen con recursos del SGSI, así como a todos los sistemas on-premise, servidores virtuales, redes inalámbricas, servicios SaaS y plataformas cloud operadas por la organización.
3. Principios y Directrices Mandatorias:
- Mínimo Privilegio (Least Privilege): Todo usuario dispondrá únicamente de los permisos estrictamente imprescindibles para desempeñar sus funciones laborales asignadas.
- Necesidad de Conocer (Need-to-Know): El acceso a la información confidencial o restringida requiere autorización expresa del propietario del activo de información.
- Identificación Individual: Queda prohibido el uso de cuentas genéricas, compartidas o anónimas. Toda acción debe ser trazable a una persona física identificable, salvo cuentas de servicio de sistemas automatizados previamente inventariadas.
- Autenticación Multifactor (MFA): El uso de MFA es obligatorio para todo acceso remoto externo, para el acceso a consolas de administración en la nube y para el acceso a aplicaciones que procesen datos de clientes o datos personales especialmente protegidos.
- Segregación de Funciones (Separation of Duties): Los roles que desarrollen código no dispondrán de privilegios administrativos directos para desplegar en entornos de producción sin revisión independiente.
4. Responsabilidades:
- Propietario del Activo (Asset Owner): Responsable de autorizar formalmente las solicitudes de alta, modificación o baja de accesos sobre sus aplicaciones.
- Equipo de TI / Operaciones: Responsable de ejecutar técnicamente las altas y revocaciones de credenciales de acuerdo con las aprobaciones recibidas, y deshabilitar accesos el mismo día de la rescisión laboral.
- Responsable de Seguridad (CISO): Responsable de coordinar auditorías trimestrales de revisión de cuentas privilegiadas y verificar la aplicación de las políticas.
- Usuarios: Responsables de custodiar sus factores de autenticación, no compartir credenciales y reportar inmediatamente cualquier indicio de compromiso.
5. Gestión de Excepciones: Toda excepción a esta política (por ejemplo, un sistema heredado que no admita MFA nativo) debe solicitarse formalmente mediante ticket, documentar el riesgo residual, implementar controles compensatorios obligatorios (como aislamiento en VLAN dedicada y monitorización reforzada de logs), contar con la aprobación expresa y conjunta del CISO y el Propietario del Activo, y tener una caducidad máxima no prorrogable superior a 90 días naturales.
6. Revisión y Control de Cambios: Este documento se revisará con periodicidad anual o ante cambios significativos en la infraestructura de identidades. Propietario: CISO. Aprobado por: Comité de Seguridad de la Información (2026-09-15).
Observa la elegancia pedagógica del ejemplo: la política establece con claridad qué principios deben cumplirse obligatoriamente (MFA, segregación, mínimo privilegio, prohibición de cuentas compartidas), pero no incluye manuales de uso ni capturas de pantalla de Microsoft Entra ID o AWS IAM. Los manuales pertenecen a los procedimientos e instrucciones técnicas; la política mantiene su vigencia estratégica independientemente de si la empresa cambia de software de identidades.
Errores frecuentes al diseñar y mantener políticas de seguridad
Durante las auditorías de certificación y las evaluaciones de madurez del SGSI, suelen identificarse patrones viciosos en la redacción y gestión documental. Conocerlos de antemano permite ahorrar meses de retrabajo:
| Error Habitual | Manifestación en la Organización | Impacto en el SGSI y Auditoría |
|---|---|---|
| Copiar plantillas sin adaptar | Políticas que mencionan herramientas que la empresa no usa o directivas imposibles de aplicar en su infraestructura real. | Pérdida inmediata de credibilidad ante el auditor y no conformidad mayor por falta de aplicación real. |
| Hipertrofia documental | Crear 30 o 40 políticas separadas en una organización pequeña de 20 empleados. | Documentos desactualizados, fatiga de mantenimiento y desconocimiento total por parte de la plantilla. |
| Políticas enciclopédicas | Documentos de 60 páginas redactados en jerga jurídica ininteligible. | Nadie en la empresa lee las políticas; los empleados firman sin comprender las reglas básicas de seguridad. |
| Normas inaplicables | «Queda terminantemente prohibido conectar cualquier memoria USB» en una fábrica donde la maquinaria se programa por USB. | Genera una cultura de incumplimiento generalizado y crea excepciones no gestionadas que anulan el control. |
| Políticas fantasma | Documentos aprobados formalmente pero guardados en carpetas de red inaccesibles o desconocidas para los usuarios. | Incumplimiento directo de los requisitos de comunicación y toma de conciencia (cláusulas 7.3 y 7.4). |
| Contradicciones normativas | La política de teletrabajo permite usar ordenadores personales (BYOD) pero la política de puestos de trabajo lo prohíbe explícitamente. | Confusión operativa, desprotección jurídica y no conformidad por falta de coherencia interna. |
| Roles y comités ficticios | La política asigna responsabilidades a comités o cargos que no existen en el organigrama oficial. | El auditor solicita las actas de dicho comité o entrevista al cargo y constata que las funciones no se ejecutan. |
| Falta de aprobación directiva | Documentos marcados como «Borrador» o sin firma ni acta de aprobación por la alta dirección. | Carencia de legitimidad ejecutiva; no pueden exigirse disciplinariamente ni considerarse vigentes ante ISO 27001. |
| Versiones descontroladas | Diferentes versiones de una misma política conviviendo en carpetas de red locales o impresas en papel. | Incumplimiento flagrante del control de la información documentada (cláusula 7.5). |
| Revisiones caducadas | Políticas aprobadas en 2022 cuya fecha de próxima revisión indicaba 2023 y nunca volvieron a evaluarse. | Evidencia de dejadez en la mejora continua y en el mantenimiento periódico del sistema de gestión. |
| Confundir política con procedimiento | Incluir capturas de pantalla de la consola de administración en el texto de la política de seguridad. | Cada actualización menor del software deja obsoleta la política, obligando a rehacer el circuito de firmas directivas. |
| Documentación de escaparate | Políticas redactadas exclusivamente para enseñar al auditor que no tienen ningún reflejo en la configuración técnica real. | El auditor descubre la discrepancia en cuanto realiza un muestreo de cuentas o servidores reales. |
Qué busca un auditor al evaluar las políticas del SGSI
Un auditor de certificación no se limita a comprobar que los documentos existan en un disco duro. Su labor consiste en verificar la coherencia, la gobernanza y la aplicación real del marco documental. Para preparar esta fase con rigor, te aconsejamos consultar nuestra guía sobre auditoría interna en ISO 27001 y la checklist de evaluación del SGSI.
Para no confundir conceptos durante la preparación de la auditoría, es crucial distinguir entre tres categorías:
| Categoría | Definición en el marco de evaluación | Ejemplo concreto en políticas |
|---|---|---|
| Requisito Normativo | Obligación estricta impuesta por el texto de la norma ISO/IEC 27001:2022. Su ausencia genera una no conformidad. | Que la política de seguridad esté aprobada por la dirección, documentada, comunicada y disponible (Cláusula 5.2). |
| Evidencia Habitual | Información objetiva que el auditor solicita típicamente para comprobar que el requisito se cumple en la práctica. | Acta de reunión del Comité Ejecutivo donde se aprobó la política, registros del LMS de lectura por empleados o logs de MFA. |
| Buena Práctica | Recomendación metodológica de ISO/IEC 27002 o de la industria que optimiza el sistema pero no es exigible literalmente. | Separar la política de control de acceso en un documento temático independiente de no más de 5 páginas. |
Durante las entrevistas de auditoría, el evaluador seguirá un proceso de triangulación:
- Revisa el documento: Constata que la política existe, tiene control de cambios, está aprobada por la dirección y define principios claros.
- Entrevista a la plantilla: Pregunta a empleados de diferentes áreas (no solo al CISO) si conocen las políticas de uso aceptable o control de accesos, dónde pueden consultarlas y qué harían ante un incidente sospechoso.
- Muestrea la evidencia técnica: Si la política establece que las contraseñas deben rotarse ante compromiso o que el teletrabajo requiere disco cifrado con BitLocker/FileVault, el auditor pedirá comprobar una muestra aleatoria de 5 ordenadores portátiles de empleados. Si 2 de ellos no tienen el disco cifrado y no existe una excepción formal aprobada, se emitirá una no conformidad.
Por último, el auditor comprobará que las políticas se revisan anualmente y que sus resultados forman parte de las entradas de la revisión por la dirección (cláusula 9.3), alimentando el ciclo de mejora continua y madurez del SGSI (cláusula 10).
Preguntas frecuentes sobre políticas ISO 27001
¿Cuántas políticas de seguridad exige exactamente ISO/IEC 27001:2022?
La norma exige de forma explícita y obligatoria una Política de Seguridad de la Información general en su Cláusula 5.2. En el Anexo A, el Control 5.1 menciona «políticas para la seguridad de la información» en plural, lo que exige contar con directrices temáticas específicas para los controles aplicables según la Declaración de Aplicabilidad (SoA). Sin embargo, ISO no fija un número de documentos: una organización puede tener 15 políticas temáticas separadas o agruparlas en un único manual unificado.
¿Cada cuánto tiempo es obligatorio revisar las políticas?
ISO/IEC 27001 establece que deben revisarse «a intervalos planificados o cuando ocurran cambios significativos». La buena práctica consolidada en la industria fija ese intervalo planificado en un año. Además, deben revisarse de forma extraordinaria ante incidentes de seguridad de impacto relevante, reformas legislativas (como la transposición de NIS2 o normativas sectoriales) o transformaciones profundas en la arquitectura técnica.
¿Quién debe firmar y aprobar las políticas?
La política general de alto nivel (cláusula 5.2) debe ser aprobada obligatoriamente por la alta dirección (CEO, Director General o Consejo de Administración) para evidenciar liderazgo. Las políticas temáticas de segundo nivel (control A.5.1) pueden ser aprobadas por el CISO, el Comité de Seguridad de la Información o el Director de Tecnología, siempre que la alta dirección haya delegado formalmente esa autoridad mediante las responsabilidades del SGSI (cláusula 5.3).
¿Es obligatorio que todos los empleados firmen físicamente la recepción de las políticas?
No. ISO 27001 exige que las políticas sean comunicadas (7.4) y que el personal tome conciencia de su contribución a la eficacia del SGSI (7.3). La firma física en papel es una opción tradicional, pero hoy en día es mucho más eficiente y común utilizar plataformas de onboarding digital, acuses de recibo en la intranet o módulos de sensibilización en plataformas LMS con registro electrónico demostrable.
¿Qué diferencia sustancial hay entre la Cláusula 5.2 y el Control A.5.1?
La Cláusula 5.2 es un requisito normativo de gobernanza del sistema de gestión que obliga a la alta dirección a emitir una política marco que fije los compromisos institucionales y el marco para los objetivos. El Control A.5.1 es un control operacional del Anexo A concebido para regular el ciclo de vida, la difusión y la actualización del conjunto completo de políticas (tanto la general como las temáticas operativas).
