Políticas de ISO 27001: Qué Políticas Necesita y Cómo Redactarlas

Las políticas son la columna vertebral de todo Sistema de Gestión de Seguridad de la Información (ISMS) de ISO 27001. Traducen las intenciones de seguridad de la dirección en compromisos documentados que guían el comportamiento de los empleados, definen los objetivos de control y proporcionan a los auditores algo concreto contra lo cual evaluar. Sin políticas bien estructuradas y aplicables, su ISMS existe solo en teoría.

Muchas empresas SaaS abordan las políticas de ISO 27001 de la manera incorrecta. Descargan plantillas genéricas, reemplazan el nombre de la empresa y asumen que están listos. Esto crea dos problemas. Primero, las políticas no reflejan cómo opera realmente la organización, lo que significa que los empleados las ignoran. Segundo, los auditores de certificación detectan la desconexión inmediatamente — han visto las mismas plantillas cientos de veces y saben cuándo una política no fue escrita para la organización que la presenta.

Esta guía cubre los requisitos de información documentada en ISO 27001, cada política obligatoria y recomendada, cómo estructurar y redactar políticas que funcionen para empresas SaaS, y cómo gestionar el ciclo de vida de aprobación, comunicación y revisión que exige el estándar.

Lo que ISO 27001 Dice sobre la Información Documentada

ISO 27001 utiliza el término “información documentada” en lugar de “documentos” o “registros”. Esto es deliberado — el estándar no prescribe formatos de documentos específicos, convenciones de nomenclatura ni estructuras. Requiere que cierta información sea documentada, mantenida y controlada, pero cómo organice esa información depende de usted.

La Cláusula 7.5 establece los requisitos generales para la información documentada. Indica que su ISMS debe incluir la información documentada requerida por el propio estándar, más cualquier información documentada adicional que su organización determine necesaria para la eficacia del ISMS.

Lo que el Estándar Requiere Explícitamente

La siguiente información documentada es directamente exigida por las cláusulas de ISO 27001:2022:

• Alcance del ISMS (Cláusula 4.3) — Los límites y aplicabilidad de su ISMS
• Política de seguridad de la información (Cláusula 5.2) — La política de nivel superior que expresa la dirección de la gestión
• Proceso de evaluación de riesgos (Cláusula 6.1.2) — Cómo identifica, analiza y evalúa los riesgos de seguridad de la información
• Proceso de tratamiento de riesgos (Cláusula 6.1.3) — Cómo selecciona e implementa controles para abordar los riesgos identificados
• Objetivos de seguridad de la información (Cláusula 6.2) — Metas medibles para su programa de seguridad
• Evidencia de competencia (Cláusula 7.2) — Prueba de que las personas que realizan trabajo relevante para la seguridad son competentes
• Planificación y control operacional (Cláusula 8.1) — Documentación de los procesos necesarios para cumplir los requisitos de seguridad
• Resultados de la evaluación de riesgos (Cláusula 8.2) — Resultado de las evaluaciones de riesgos completadas
• Resultados del tratamiento de riesgos (Cláusula 8.3) — Resultado de las actividades de tratamiento de riesgos
• Resultados de monitoreo y medición (Cláusula 9.1) — Evidencia de la evaluación del rendimiento
• Programa y resultados de auditoría interna (Cláusula 9.2) — Planes de auditoría, criterios, alcance y hallazgos
• Resultados de la revisión por la dirección (Cláusula 9.3) — Resultado de las reuniones de revisión por la dirección
• No conformidades y acciones correctivas (Cláusula 10.1) — Registros de los problemas encontrados y cómo se abordaron
• Declaración de Aplicabilidad (Cláusula 6.1.3 d) — Lista de todos los controles del Annex A con justificación para su inclusión o exclusión

Este es el conjunto mínimo. La mayoría de las organizaciones necesitan significativamente más información documentada para demostrar que su ISMS opera eficazmente.

La Declaración de Aplicabilidad como Mapa de Políticas

La Declaración de Aplicabilidad (SoA) merece atención especial porque funciona como el puente entre sus decisiones de tratamiento de riesgos y las políticas que implementan esas decisiones. Para cada control del Annex A que declare aplicable, necesita información documentada que describa cómo se implementa ese control. En la práctica, esto significa que su SoA impulsa su lista de políticas — cada control aplicable debe rastrearse a una política, procedimiento o estándar que lo gobierne.

Políticas Obligatorias

ISO 27001 no proporciona una lista numerada de documentos de política requeridos. En su lugar, ciertas cláusulas y controles del Annex A requieren implícita o explícitamente documentación a nivel de política. Las siguientes políticas se consideran obligatorias para la certificación.

1. Política de Seguridad de la Información

Referencia de cláusula: 5.2, A.5.1

Este es el documento principal de su ISMS. Establece el compromiso de la organización con la seguridad de la información, marca la dirección para todas las políticas subordinadas y está firmado por la alta dirección.

Lo que debe contener:

• El propósito y alcance del ISMS
• Un compromiso de satisfacer los requisitos de seguridad aplicables
• Un compromiso de mejora continua del ISMS
• Un marco para establecer objetivos de seguridad de la información
• Asignación de la responsabilidad general de la seguridad de la información

Lo que no debe contener: Procedimientos operativos detallados, configuraciones técnicas específicas o implementaciones de controles. La política de seguridad de la información es un documento estratégico. Manténgala lo suficientemente general para que no necesite cambiar cada vez que modifique un control técnico.

Ejemplo SaaS: Su política de seguridad de la información declara que la organización está comprometida con la protección de los datos de clientes procesados a través de su plataforma en la nube, que los objetivos de seguridad se revisan trimestralmente por el equipo de liderazgo y que el CTO es responsable del programa de seguridad de la información. Referencia el conjunto completo de políticas subordinadas (control de acceso, respuesta a incidentes, etc.) sin duplicar su contenido.

Hallazgo común de auditoría: La política existe pero nunca ha sido revisada ni actualizada desde su creación inicial. Los auditores verifican las fechas de revisión. Si su política tiene tres años y su empresa ha cambiado significativamente, lo señalarán.

2. Metodología de Evaluación y Tratamiento de Riesgos

Referencia de cláusula: 6.1.2, 6.1.3

Esta metodología documentada define cómo su organización identifica, analiza, evalúa y trata los riesgos de seguridad de la información. No es el registro de riesgos en sí — es la descripción del proceso que asegura que las evaluaciones de riesgos sean consistentes y repetibles.

Lo que debe contener:

• Criterios de identificación de riesgos (qué constituye un riesgo, enfoque basado en activos vs. basado en escenarios)
• Método de análisis de riesgos (cualitativo, cuantitativo o semicuantitativo)
• Escalas de probabilidad e impacto con definiciones claras para cada nivel
• Criterios de evaluación de riesgos (cómo determina qué riesgos son aceptables y cuáles requieren tratamiento)
• Criterios de aceptación de riesgos y quién tiene autoridad para aceptar el riesgo residual
• Opciones de tratamiento de riesgos (mitigar, transferir, aceptar, evitar) y criterios de selección

Para un recorrido detallado del proceso de evaluación de riesgos, consulte nuestra guía de Evaluación de Riesgos ISO 27001.

Ejemplo SaaS: Utiliza una matriz de riesgo cualitativa de 5x5. La probabilidad se califica de Rara (1) a Casi Segura (5) basándose en datos históricos e inteligencia de amenazas. El impacto se califica de Despreciable (1) a Crítico (5) basándose en consecuencias financieras, operativas, reputacionales y regulatorias. Los riesgos con puntuación de 15 o superior requieren tratamiento. Los riesgos con puntuación de 9-14 requieren justificación documentada si se aceptan. El CTO tiene autoridad para aceptar riesgos con puntuación de 14 o inferior; los riesgos con puntuación de 15 o superior requieren aprobación del CEO.

3. Declaración de Aplicabilidad

Referencia de cláusula: 6.1.3 d

La Declaración de Aplicabilidad lista los 93 controles del Annex A de ISO 27001:2022 con una determinación de si cada uno es aplicable, la justificación para su inclusión o exclusión, y una referencia de cómo se implementa cada control aplicable.

El SoA es uno de los documentos más importantes de su ISMS. Los auditores lo usan como su hoja de ruta — seleccionan controles del SoA y prueban si esos controles están implementados y operando según lo descrito.

Hallazgo común de auditoría: El SoA dice que un control está implementado, pero la política o procedimiento referenciado no existe, o existe pero no se está siguiendo. Cada afirmación en su SoA debe ser verificable.

4. Plan de Tratamiento de Riesgos

Referencia de cláusula: 6.1.3, 8.3

El plan de tratamiento de riesgos documenta las acciones específicas que tomará para abordar los riesgos que excedan sus criterios de aceptación. Para cada riesgo que requiere tratamiento, el plan identifica los controles a implementar, la persona responsable, el cronograma y los recursos necesarios.

Lo que debe contener:

• Riesgos identificados que requieren tratamiento (vinculados al registro de riesgos)
• Opción de tratamiento seleccionada para cada riesgo
• Controles a aplicar (referenciando el Annex A u otras fuentes)
• Propietario de implementación y cronograma
• Riesgo residual esperado después del tratamiento
• Seguimiento de estado

Políticas Recomendadas para Empresas SaaS

Más allá de la información documentada obligatoria, las empresas SaaS que buscan la certificación ISO 27001 necesitan políticas adicionales para satisfacer los controles del Annex A y demostrar un ISMS maduro. El conjunto exacto depende de su SoA, pero las siguientes políticas son esperadas por prácticamente todo auditor de certificación.

5. Política de Control de Acceso

Referencia del Annex A: A.5.15 (Control de acceso), A.5.16 (Gestión de identidad), A.5.17 (Información de autenticación), A.5.18 (Derechos de acceso), A.8.2 (Derechos de acceso privilegiado), A.8.3 (Restricción de acceso a la información), A.8.5 (Autenticación segura)

El control de acceso es una de las áreas más intensamente evaluadas en cualquier auditoría de ISO 27001. Su política de control de acceso define cómo la organización gestiona las identidades de usuario, autenticación, autorización y el ciclo de vida completo de los derechos de acceso. Para una inmersión profunda en la implementación, consulte nuestra guía de Control de Acceso ISO 27001.

Lo que cubre:

• Proceso de registro y cancelación de registro de usuarios
• Modelo de control de acceso basado en roles (RBAC) o control de acceso basado en atributos (ABAC)
• Principio de privilegio mínimo
• Requisitos de autenticación multifactor (MFA)
• Gestión de acceso privilegiado (PAM)
• Gobernanza de cuentas de servicio y claves API
• Frecuencia y proceso de revisión periódica de acceso
• Cronograma de desaprovisionamiento ante cambio de rol o terminación

Ejemplo SaaS: Todo acceso al entorno de producción requiere MFA. Las cuentas de servicio se aprovisionan a través de Terraform con credenciales de tiempo limitado. Las revisiones de acceso se realizan trimestralmente utilizando exportaciones automatizadas de su proveedor de identidad. El desaprovisionamiento debe ocurrir dentro de las 24 horas posteriores a la notificación de terminación.

6. Política de Gestión de Activos

Referencia del Annex A: A.5.9 (Inventario de información y otros activos asociados), A.5.10 (Uso aceptable), A.5.11 (Devolución de activos), A.5.12 (Clasificación de información), A.5.13 (Etiquetado de información)

Esta política gobierna la identificación, clasificación, etiquetado y uso aceptable de los activos de información. Para empresas SaaS, los “activos” incluyen infraestructura en la nube, repositorios de código, bases de datos, herramientas SaaS y propiedad intelectual.

Lo que cubre:

• Requisitos de inventario de activos y frecuencia de mantenimiento
• Esquema de clasificación de información (por ejemplo, Pública, Interna, Confidencial, Restringida)
• Reglas de etiquetado para cada nivel de clasificación
• Reglas de uso aceptable para activos organizacionales (incluyendo BYOD)
• Procedimientos de devolución de activos al salir el empleado

Ejemplo SaaS: Clasifica los datos en cuatro niveles. Los datos de producción de clientes son Restringidos. Los documentos internos de negocio son Confidenciales. Las publicaciones del blog de la empresa son Públicas. Cada nivel de clasificación se mapea a requisitos específicos de manejo — los datos Restringidos deben estar cifrados en reposo y en tránsito, el acceso requiere aprobación del propietario de los datos y no pueden almacenarse fuera de los entornos de producción aprobados.

7. Política de Seguridad de Recursos Humanos

Referencia del Annex A: A.6.1 (Verificación de antecedentes), A.6.2 (Términos y condiciones de empleo), A.6.3 (Conciencia de seguridad de la información), A.6.4 (Proceso disciplinario), A.6.5 (Responsabilidades después de la terminación)

Esta política cubre los aspectos de seguridad de todo el ciclo de vida del empleado — desde la verificación previa al empleo, pasando por la incorporación, el empleo continuo y la terminación.

Lo que cubre:

• Requisitos de verificación de antecedentes (alcance y frecuencia)
• Obligaciones de confidencialidad y seguridad en los contratos de empleo
• Requisitos de formación en conciencia de seguridad (inicial y recurrente)
• Expectativas de conducta aceptable y proceso disciplinario por violaciones
• Procedimientos de terminación y salida (revocación de acceso, devolución de activos, transferencia de conocimiento)

Ejemplo SaaS: Todos los empleados se someten a una verificación de antecedentes antes de su fecha de inicio. La formación en conciencia de seguridad se completa dentro de la primera semana de empleo y anualmente a partir de entonces. Todos los empleados firman un acuerdo de confidencialidad que cubre los datos de los clientes. Al terminarse la relación laboral, se notifica a TI dentro de las 4 horas y se revoca todo el acceso antes del final del último día laboral del empleado.

8. Política de Gestión de Incidentes

Referencia del Annex A: A.5.24 (Planificación y preparación de la gestión de incidentes de seguridad de la información), A.5.25 (Evaluación y decisión sobre eventos de seguridad de la información), A.5.26 (Respuesta a incidentes de seguridad de la información), A.5.27 (Aprendizaje de los incidentes de seguridad de la información), A.5.28 (Recopilación de evidencia), A.6.8 (Reporte de eventos de seguridad de la información)

Esta política define cómo su organización detecta, reporta, evalúa, responde y aprende de los incidentes de seguridad de la información.

Lo que cubre:

• Definiciones de evento e incidente de seguridad (y la distinción entre ambos)
• Esquema de clasificación de severidad (por ejemplo, P1-P4)
• Canales de reporte y responsabilidades (quién reporta qué, a quién y con qué rapidez)
• Procedimientos de escalamiento basados en severidad
• Pasos de contención, erradicación y recuperación
• Requisitos de preservación de evidencia
• Proceso de revisión post-incidente
• Obligaciones de notificación externa (reguladores, clientes, fuerzas del orden)

Ejemplo SaaS: Cualquier empleado que sospeche de un evento de seguridad lo reporta inmediatamente a través del canal de Slack #incidentes-seguridad. El ingeniero de seguridad de guardia hace el triaje dentro de los 30 minutos. Los incidentes P1 (violación de datos confirmada, intrusión activa) activan una sala de guerra y requieren notificación al cliente dentro de las 72 horas. Cada incidente P1 y P2 recibe una autopsia escrita dentro de cinco días hábiles.

9. Política de Continuidad del Negocio

Referencia del Annex A: A.5.29 (Seguridad de la información durante la interrupción), A.5.30 (Preparación de las TIC para la continuidad del negocio), A.8.13 (Copias de seguridad de la información), A.8.14 (Redundancia de las instalaciones de procesamiento de información)

Esta política establece cómo la organización mantiene la seguridad de la información durante eventos disruptivos y asegura la disponibilidad de los servicios críticos.

Lo que cubre:

• Requisitos de análisis de impacto en el negocio (BIA)
• Objetivos de tiempo de recuperación (RTO) y objetivos de punto de recuperación (RPO) para servicios críticos
• Política de copias de seguridad (alcance, frecuencia, retención, pruebas)
• Procedimientos de recuperación ante desastres
• Programa de pruebas y ejercicios
• Plan de comunicación durante interrupciones

Ejemplo SaaS: Las bases de datos de producción se respaldan cada hora con un RPO de 1 hora y un RTO de 4 horas. Las copias de seguridad se almacenan en una región de AWS separada y se prueban mensualmente mediante una restauración completa a un entorno de staging. Los ejercicios de mesa de recuperación ante desastres se realizan trimestralmente. La página de estado se actualiza dentro de los 15 minutos posteriores a cualquier interrupción del servicio.

10. Política de Proveedores y Terceros

Referencia del Annex A: A.5.19 (Seguridad de la información en las relaciones con proveedores), A.5.20 (Abordaje de la seguridad de la información dentro de los acuerdos con proveedores), A.5.21 (Gestión de la seguridad de la información en la cadena de suministro de TIC), A.5.22 (Monitoreo, revisión y gestión de cambios de los servicios de proveedores), A.5.23 (Seguridad de la información para el uso de servicios en la nube)

Esta política gobierna cómo su organización evalúa, incorpora, monitorea y desvincula a proveedores externos que acceden, procesan o almacenan sus datos o los datos de sus clientes.

Lo que cubre:

• Metodología y frecuencia de evaluación de riesgos de proveedores
• Requisitos de seguridad para acuerdos con proveedores (protección de datos, notificación de incidentes, derechos de auditoría)
• Proceso de debida diligencia para nuevos proveedores (cuestionarios de seguridad, revisión de informes SOC 2/ISO 27001)
• Cadencia de monitoreo continuo (revisión anual, monitoreo continuo para proveedores críticos)
• Gestión de subprocesadores
• Requisitos de seguridad para proveedores de servicios en la nube

Ejemplo SaaS: Todos los proveedores que procesan datos de clientes se someten a una evaluación de seguridad antes de la incorporación. Los proveedores críticos (infraestructura, identidad, procesamiento de pagos) se revisan anualmente y deben proporcionar un certificado SOC 2 Tipo II o ISO 27001 vigente. Los acuerdos con proveedores incluyen cláusulas de procesamiento de datos, notificación de violaciones dentro de las 48 horas y el derecho a auditar.

11. Política de Criptografía

Referencia del Annex A: A.8.24 (Uso de criptografía)

Esta política define el enfoque de la organización para usar controles criptográficos para proteger la confidencialidad, integridad y autenticidad de la información.

Lo que cubre:

• Requisitos de cifrado por nivel de clasificación de datos
• Algoritmos criptográficos aprobados y longitudes mínimas de clave
• Procedimientos de gestión de claves (generación, distribución, almacenamiento, rotación, revocación, destrucción)
• Requisitos de TLS/SSL para datos en tránsito
• Requisitos de cifrado en reposo
• Gestión de certificados

Ejemplo SaaS: Todos los datos en tránsito usan TLS 1.2 o superior. Los datos de clientes en reposo se cifran usando AES-256. Las claves de cifrado de bases de datos se gestionan a través de AWS KMS con rotación automática anual. Las claves SSH requieren ED25519 o RSA-4096. Los certificados se gestionan a través de ACM con renovación automatizada.

12. Política de Seguridad Física

Referencia del Annex A: A.7.1 hasta A.7.14

Para empresas SaaS que operan enteramente en la nube, la política de seguridad física a menudo tiene un alcance limitado a las instalaciones de oficina y los endpoints de los empleados. La seguridad física de la infraestructura en la nube está típicamente cubierta por las propias certificaciones del proveedor de nube.

Lo que cubre:

• Control de acceso a oficinas (acceso con tarjeta, gestión de visitantes)
• Áreas seguras (salas de servidores si aplica, zonas restringidas de oficina)
• Seguridad de equipos (cifrado de portátiles, bloqueo de pantalla, eliminación segura)
• Requisitos de seguridad para trabajo remoto
• Política de escritorio y pantalla limpios

Ejemplo SaaS: Su política de seguridad física reconoce que la infraestructura de producción se ejecuta en AWS (seguridad física gobernada por las propias certificaciones ISO 27001 y SOC 2 de AWS). La política se enfoca en el acceso a oficinas (acceso con tarjeta requerido, los visitantes deben ser escoltados y registrados), seguridad de endpoints (cifrado FileVault/BitLocker obligatorio, bloqueo de pantalla después de 5 minutos) y trabajo remoto (VPN requerida para acceso a herramientas internas, el trabajo no debe realizarse en computadoras públicas).

13. Política de Seguridad de Operaciones

Referencia del Annex A: A.8.6 (Gestión de capacidad), A.8.7 (Protección contra malware), A.8.8 (Gestión de vulnerabilidades técnicas), A.8.9 (Gestión de configuración), A.8.15 (Registro), A.8.16 (Actividades de monitoreo)

Esta política cubre los controles de seguridad operacional del día a día que mantienen sus sistemas seguros y observables.

Lo que cubre:

• Procesos de gestión de cambios y despliegue
• Planificación de capacidad
• Separación de entornos de desarrollo, pruebas y producción
• Protección contra malware para endpoints
• Gestión de vulnerabilidades (frecuencia de escaneo, SLAs de parcheo por severidad)
• Requisitos de registro y monitoreo
• Gestión de configuración y líneas base de endurecimiento

Ejemplo SaaS: Las vulnerabilidades críticas (CVSS 9.0+) deben parchearse dentro de las 72 horas. Las vulnerabilidades altas (CVSS 7.0-8.9) dentro de los 30 días. Todos los sistemas de producción envían registros a un SIEM centralizado con retención de 90 días. Los entornos de desarrollo, staging y producción están aislados con cuentas de AWS separadas. El software de detección y respuesta de endpoints (EDR) se ejecuta en todos los portátiles de los empleados.

14. Política de Seguridad de Comunicaciones y Transferencia de Datos

Referencia del Annex A: A.5.14 (Transferencia de información), A.8.20 (Seguridad de redes), A.8.21 (Seguridad de servicios de red), A.8.22 (Segregación de redes), A.8.23 (Filtrado web)

Esta política gobierna cómo se transfiere la información dentro y fuera de la organización, y cómo se mantiene la seguridad de la red.

Lo que cubre:

• Canales aprobados para la transferencia de información por nivel de clasificación
• Requisitos de seguridad del correo electrónico
• Reglas de segmentación de red
• Seguridad de red inalámbrica
• Requisitos de acceso remoto (VPN, confianza cero)
• Acuerdos de transferencia de datos con partes externas

Cómo Estructurar una Política de ISO 27001

Una estructura de política consistente no es un requisito formal, pero mejora dramáticamente la usabilidad y demuestra madurez. Cuando cada política sigue la misma plantilla, los empleados saben dónde encontrar la información y los auditores pueden navegar su documentación eficientemente.

Secciones Recomendadas de Política

1. Bloque de control de documentos

Cada política debe comenzar con metadatos:

• Título de la política e identificador único (por ejemplo, POL-ISP-001)
• Número de versión
• Propietario de la política (nombre y rol)
• Aprobador (nombre y rol)
• Fecha de vigencia
• Fecha de próxima revisión
• Nivel de clasificación (típicamente Interno o Confidencial)

2. Propósito

Uno o dos párrafos explicando por qué existe esta política y qué problema aborda. Esto debe responder: “¿Por qué debería importarme esta política?”

Ejemplo: “Esta Política de Control de Acceso establece los requisitos para gestionar el acceso de usuarios a los sistemas de información y datos durante todo el ciclo de vida del acceso. Existe para prevenir el acceso no autorizado, mantener el principio de privilegio mínimo y asegurar que los derechos de acceso sigan siendo apropiados a medida que los empleados se incorporan, se mueven dentro de la organización o la abandonan.”

3. Alcance

Defina exactamente a quién y a qué aplica la política. Sea específico sobre inclusiones y exclusiones.

Ejemplo: “Esta política aplica a todos los empleados, contratistas y usuarios de terceros que acceden a los sistemas de información de [Empresa]. Cubre todos los sistemas de producción, aplicaciones corporativas y servicios en la nube dentro del alcance del ISMS tal como se define en la Declaración de Alcance del ISMS (DOC-ISMS-001). No cubre el acceso físico a las instalaciones de oficina, que está gobernado por la Política de Seguridad Física (POL-PHY-001).”

4. Declaraciones de política

El núcleo del documento. Cada declaración de política debe ser:

• Clara e inequívoca — Sin margen para interpretación
• Medible — Puede determinar objetivamente el cumplimiento
• Realista — Alcanzable con los recursos y tecnología actuales
• Atribuible — Alguien es responsable del cumplimiento

Redacte las declaraciones de política como requisitos, no sugerencias. Use “debe” para requisitos obligatorios, “debería” para recomendaciones y “puede” para permisos.

5. Roles y responsabilidades

Defina quién es responsable de qué. Use títulos de roles, no nombres individuales, para que la política sobreviva a los cambios de personal.

Ejemplo:

• Gerente de Seguridad de la Información: Mantiene esta política, realiza revisiones anuales e informa del estado de cumplimiento al liderazgo
• Equipo de Operaciones de TI: Implementa los controles técnicos definidos en esta política
• Operaciones de Personal: Notifica a TI de las terminaciones de empleados dentro de las 4 horas
• Todos los empleados: Cumplen con esta política y reportan sospechas de violaciones

6. Documentos relacionados

Liste los estándares, procedimientos y otras políticas que apoyan o se conectan con esta política. Esto crea trazabilidad a lo largo de su marco de documentación.

7. Definiciones y abreviaturas

Defina cualquier término que pueda ser ambiguo. Esto es especialmente importante cuando audiencias técnicas y no técnicas leen la política.

8. Historial de revisión y versiones

Una tabla que muestra cada revisión: fecha, versión, autor y una breve descripción de los cambios.

Redacción de Políticas para Empresas SaaS

Las empresas SaaS tienen características distintas que deben moldear cómo se redactan las políticas. Ignorar estas características produce políticas que son técnicamente conformes pero operacionalmente inútiles.

Redacte para su flujo de trabajo real. Si su equipo de ingeniería despliega a producción 20 veces al día usando un pipeline CI/CD, su política de gestión de cambios debe describir ese proceso — no un comité asesor de cambios tradicional que se reúne semanalmente. Los auditores no penalizan las prácticas modernas. Penalizan las discrepancias entre lo que documenta y lo que hace.

Sea específico sobre los servicios en la nube. Las referencias genéricas a “servidores” y “centros de datos” indican que una política fue escrita para un tipo diferente de empresa. Nombre sus proveedores de nube. Referencie servicios específicos (AWS RDS, Azure AD, GCP Cloud Run). Esta especificidad ayuda a los empleados a entender qué significa la política en la práctica y ayuda a los auditores a verificar el cumplimiento.

Mantenga las políticas concisas. Una política de control de acceso de 50 páginas señala burocracia, no madurez. Los auditores y empleados prefieren documentos que sean exhaustivos pero no verbosos. Si una sección crece más allá de una página, considere si el detalle pertenece a un procedimiento o estándar de soporte en lugar de la política misma.

Use lenguaje que su equipo entienda. Si su equipo usa “deploy” en lugar de “liberar”, use “deploy”. Si dicen “repo” en lugar de “repositorio”, use “repo”. Las políticas que usan lenguaje desconocido son ignoradas.

Establezca compromisos alcanzables. Cada declaración de política se convierte en una obligación verificable. Si su política dice que las contraseñas deben rotarse cada 30 días, debe demostrar que se rotan. Si su política dice que las revisiones de acceso ocurren trimestralmente, necesita cuatro revisiones completadas por año. El hallazgo de auditoría más común en todas las certificaciones de ISO 27001 es que las organizaciones no cumplen con sus propios requisitos declarados. Establezca estándares que pueda cumplir consistentemente, luego elévelos con el tiempo a través de la mejora continua.

Aprobación y Comunicación

Aprobación de Políticas

La Cláusula 5.2 requiere que la política de seguridad de la información sea aprobada por la alta dirección. En la práctica, los auditores esperan que todas las políticas del ISMS pasen por un proceso formal de aprobación.

Quién aprueba: El aprobador debe ser alguien con autoridad suficiente para comprometer a la organización con los requisitos de la política. Para la política de seguridad de la información de nivel superior, esto es típicamente el CEO, CTO o un miembro del equipo ejecutivo. Para políticas subordinadas, el gerente de seguridad de la información o el CTO suele ser apropiado.

Cómo documentar la aprobación: Manténgalo simple. Las opciones incluyen:

• Firma digital en el documento de la política
• Aprobación registrada en su sistema de gestión de documentos (con marca de tiempo e identidad del aprobador)
• Confirmación por correo electrónico o Slack capturada y almacenada como evidencia
• Aprobación a través de una plataforma GRC con pista de auditoría

Lo que importa es que pueda demostrar quién aprobó la política, cuándo la aprobaron y qué versión aprobaron.

Comunicación de Políticas

La Cláusula 7.4 requiere que comunique información relevante sobre el ISMS a las partes internas y, donde sea apropiado, externas. Para las políticas, esto significa:

• Todos los empleados deben saber que las políticas existen
• Los empleados deben tener acceso a las políticas relevantes para sus roles
• Los nuevos empleados deben recibir información de las políticas durante la incorporación
• Los cambios significativos de políticas deben comunicarse cuando ocurran

Enfoques prácticos para equipos SaaS:

• Almacene las políticas en una ubicación centralizada y accesible (Confluence, Notion, SharePoint o una plataforma GRC)
• Envíe una notificación cuando se creen o actualicen significativamente las políticas
• Incluya la revisión de políticas en la lista de verificación de incorporación
• Requiera un acuse de recibo anual de políticas de todos los empleados (documentado con marcas de tiempo)

Hallazgo común de auditoría: Las políticas existen en un sistema de gestión de documentos, pero los empleados no sabían que existían o no podían encontrarlas. Los auditores pueden entrevistar a empleados y preguntar dónde encontrarían la política de control de acceso. Si el empleado no puede responder, eso es una brecha de comunicación.

Acuse de Recibo de Políticas

Aunque ISO 27001 no requiere explícitamente acuses de recibo firmados, son una forma sólida de evidencia de que la comunicación ocurrió. La mayoría de los auditores de certificación esperan ver alguna forma de acuse de recibo, especialmente para políticas críticas.

Implemente un sistema donde los empleados reconozcan electrónicamente que han leído y entendido cada política. Rastree las fechas de finalización y haga seguimiento con los empleados que no hayan completado sus acuses de recibo. Esta evidencia es directamente útil durante las auditorías.

Cadencia de Revisión y Ciclo de Vida

Frecuencia de Revisión Obligatoria

ISO 27001 requiere que la información documentada sea revisada y actualizada según sea necesario (Cláusula 7.5.2). Aunque el estándar no especifica una frecuencia mínima de revisión, la expectativa universal es una revisión anual como mínimo.

Cadencia recomendada:

• Revisión anual: Cada política debe revisarse al menos una vez al año, incluso si no se necesitan cambios. Documente que la revisión ocurrió y que la política fue confirmada como vigente.
• Revisión desencadenada: Revise y actualice las políticas cuando ocurran cambios significativos — reestructuración organizacional, cambios tecnológicos importantes, nuevos requisitos regulatorios o lecciones aprendidas de incidentes de seguridad.
• Revisión post-incidente: Después de incidentes de seguridad significativos, revise las políticas relevantes para determinar si se necesitan cambios.

El Proceso de Revisión

Una revisión de políticas no es simplemente releer el documento y firmarlo. Una revisión efectiva incluye:

1. Verificación de relevancia: ¿La política aún aborda los riesgos y el contexto empresarial actuales?
2. Verificación de precisión: ¿Las declaraciones de política coinciden con las prácticas reales? Si las prácticas se han desviado de la política, actualice la política o corrija las prácticas.
3. Verificación de completitud: ¿Han surgido nuevos riesgos, tecnologías o regulaciones que la política debería abordar?
4. Aportaciones de las partes interesadas: Consulte a los equipos responsables de implementar la política. Ellos saben dónde están las brechas.
5. Aprobación: Las políticas actualizadas pasan por el mismo proceso de aprobación que las políticas nuevas.
6. Comunicación: Si se realizaron cambios, notifique a los empleados afectados y solicite acuses de recibo actualizados.

Control de Versiones

Mantenga un historial de versiones claro para cada política. Debe poder mostrar a los auditores qué versión estaba vigente durante cualquier período determinado. Esto es especialmente importante durante la transición cuando se actualizan las políticas — el auditor necesita verificar que la versión vigente durante el período de auditoría era la versión que se estaba siguiendo.

Use un esquema de versionado consistente (por ejemplo, 1.0, 1.1, 2.0) y almacene las versiones anteriores en lugar de sobrescribirlas. Una plataforma GRC o sistema de gestión de documentos con control de versiones incorporado elimina el riesgo de perder versiones históricas.

Mapeo de Políticas a Controles del Annex A

Una de las cosas más útiles que puede hacer al construir su marco de políticas es crear un mapeo explícito entre sus políticas y los controles del Annex A que abordan. Este mapeo cumple tres propósitos:

1. Garantía de completitud: Puede verificar que cada control del Annex A aplicable esté abordado por al menos una política
2. Eficiencia de auditoría: Los auditores pueden encontrar rápidamente la política relevante para cualquier control que quieran probar
3. Identificación de brechas: Puede identificar controles que están declarados como aplicables en su SoA pero carecen de documentación de soporte

Ejemplo de Mapeo

Control del Annex A	Título del Control	Política Principal	Procedimiento de Soporte
A.5.1	Políticas para la seguridad de la información	Política de Seguridad de la Información	Procedimiento de Gestión de Políticas
A.5.9	Inventario de información y otros activos asociados	Política de Gestión de Activos	Procedimiento de Inventario de Activos
A.5.15	Control de acceso	Política de Control de Acceso	Procedimiento de Aprovisionamiento de Usuarios
A.5.24	Planificación de la gestión de incidentes de seguridad de la información	Política de Gestión de Incidentes	Procedimiento de Respuesta a Incidentes
A.5.29	Seguridad de la información durante la interrupción	Política de Continuidad del Negocio	Procedimiento de Recuperación ante Desastres
A.8.24	Uso de criptografía	Política de Criptografía	Procedimiento de Gestión de Claves

Mantenga este mapeo como un documento vivo. Cuando agregue o modifique la aplicabilidad de controles del Annex A en su SoA, actualice el mapeo de políticas simultáneamente. Cuando actualice una política, verifique que el mapeo aún refleja con precisión el contenido de la política.

Políticas vs. Procedimientos vs. Estándares

Comprenda la jerarquía y mantenga las capas distintas:

• Políticas declaran qué hará la organización y por qué. Son aprobadas por la dirección y establecen la dirección. Cambian infrecuentemente.
• Estándares definen requisitos medibles específicos. Traducen la intención de la política en puntos de referencia concretos. Ejemplo: “AES-256 para datos en reposo.”
• Procedimientos describen paso a paso cómo realizar una tarea. Son operativos y pueden cambiar a medida que evolucionan las herramientas o procesos.

Los auditores esperan ver esta jerarquía reflejada en su documentación. Cuando una política referencia un procedimiento, el procedimiento debe existir. Cuando un procedimiento referencia un estándar, el estándar debe estar documentado. Las referencias rotas — políticas que apuntan a procedimientos que no existen — son un hallazgo común.

Errores Comunes en Políticas y Cómo Evitarlos

Copiar Plantillas sin Personalización

El error más generalizado. Las plantillas genéricas contienen referencias a salas de servidores físicos, rotaciones de copias de seguridad en cinta y libros de registro de visitantes que no tienen nada que ver con una empresa SaaS nativa de la nube. Cada declaración de política debe describir algo que su organización realmente hace o hará.

Solución: Use plantillas como marco inicial, luego reescriba cada sección para que coincida con su entorno, herramientas y flujos de trabajo reales. Si una sección no aplica, elimínela en lugar de dejarla como texto aspiracional.

Comprometerse en Exceso

Las organizaciones redactan políticas que describen un estado ideal en lugar de su capacidad real. Una política que requiere revisiones de seguridad de cada línea de código, pruebas de penetración semanales y búsqueda de amenazas en tiempo real suena impresionante pero crea obligaciones que son casi imposibles de sostener.

Solución: Redacte políticas que reflejen su capacidad actual, con un plan claro para elevar el listón a través de la mejora continua. Es mucho mejor tener políticas alcanzables que cumple consistentemente que políticas ambiciosas que viola consistentemente.

Sub-Documentar

El extremo opuesto — políticas tan vagas que no proporcionan orientación accionable. “La empresa protegerá sus datos” es una declaración de visión, no una política.

Solución: Cada declaración de política debe ser lo suficientemente específica para ser verificable. Pregunte: “¿Podría un auditor determinar si estamos cumpliendo con esta declaración?” Si la respuesta es no, la declaración necesita más especificidad.

Ignorar el Ciclo de Revisión

Las políticas se escriben durante la implementación inicial del ISMS y nunca se revisan. Dos años después, la empresa ha migrado de AWS a GCP, se ha duplicado en tamaño y ha lanzado tres nuevos productos, pero las políticas aún describen el entorno original.

Solución: Establezca recordatorios en el calendario para revisiones anuales. Asigne un propietario de política para cada documento que sea responsable de mantenerlo actualizado. Incorpore la revisión de políticas en el alcance de su auditoría interna.

No Conectar las Políticas con la Evidencia

Una política existe, pero no hay mecanismo para demostrar el cumplimiento. La política de control de acceso requiere revisiones de acceso trimestrales, pero nadie las ejecuta y no hay registros.

Solución: Para cada declaración de política, defina qué evidencia demostrará el cumplimiento y asegúrese de que exista un proceso para generar y conservar esa evidencia. Al construir su lista de verificación de certificación, rastree cada requisito de política a su fuente de evidencia.

Aislar las Políticas de las Operaciones

Las políticas viven en un espacio de Confluence que nadie visita. El equipo de ingeniería nunca ha leído la política de gestión de cambios porque fue escrita por el equipo de cumplimiento sin su participación.

Solución: Involucre a los equipos operativos en la creación de políticas. Redacte las políticas en el lenguaje que usan. Almacene las políticas donde ya trabajan. Si su equipo vive en Notion, ponga las políticas en Notion. Si usan GitHub, considere gestionar las políticas como Markdown en un repositorio con flujos de trabajo de revisión basados en pull requests.

Preguntas Frecuentes

¿Cuántas políticas requiere ISO 27001?

ISO 27001 no especifica un número. El estándar requiere cierta información documentada, y cómo organice esa información en políticas es su decisión. Una empresa SaaS pequeña podría tener 10-15 políticas cubriendo todos los controles del Annex A. Una organización más grande podría tener 30 o más. Lo que importa es que cada control del Annex A aplicable se rastree a cobertura de política documentada, no el recuento de documentos.

¿Puedo combinar múltiples políticas en un solo documento?

Sí. Algunas organizaciones mantienen un único “Manual de Seguridad de la Información” que contiene todas las políticas en un solo documento. Otras dividen cada tema en un documento separado. Ambos enfoques son aceptables. El enfoque de documento único es más simple de gestionar para equipos pequeños. El enfoque de múltiples documentos escala mejor a medida que la organización crece y diferentes equipos son propietarios de diferentes áreas de política.

¿Las políticas necesitan estar en un formato específico?

No. ISO 27001 no prescribe formatos de documentos. Las políticas pueden estar en documentos Word, archivos PDF, páginas wiki, archivos Markdown o gestionarse a través de una plataforma GRC. Lo que importa es que estén controladas (versionadas, aprobadas, accesibles) y revisadas.

¿Quién debería redactar las políticas?

La persona que entienda tanto la materia como las prácticas reales de la organización. En la mayoría de las empresas SaaS, esto significa colaboración entre el equipo de seguridad/cumplimiento y el equipo operativo relevante. El equipo de seguridad proporciona el marco y los objetivos de control. El equipo operativo proporciona la realidad de la implementación. Un consultor de cumplimiento puede ayudar a unir los dos.

¿Cuán larga debería ser una política?

Tan larga como sea necesario y no más. Una política típica bien redactada tiene de 3 a 8 páginas. Si una política excede las 10 páginas, considere si parte del contenido pertenece a un procedimiento o estándar de soporte. La brevedad mejora la legibilidad y adopción. Sin embargo, no sacrifique la claridad por la concisión — si una declaración de política necesita un párrafo de contexto para ser entendida, incluya el contexto.

¿Cuál es la diferencia entre las políticas de ISO 27001 y las políticas de SOC 2?

Los controles subyacentes se superponen significativamente, pero el marco de documentación difiere. Las políticas de ISO 27001 apoyan un ISMS y están organizadas alrededor de los controles del Annex A. Las políticas de SOC 2 apoyan una descripción del sistema y están organizadas alrededor de los Criterios de Servicios de Confianza. Muchas empresas SaaS que buscan ambos marcos mantienen un único conjunto de políticas que satisface ambos estándares, con un documento de mapeo que muestra cómo cada política aborda tanto los controles de ISO 27001 como los criterios de SOC 2.

Cómo Ayuda GRCTrail

GRCTrail proporciona a los equipos SaaS una solución completa de gestión de políticas construida para la certificación ISO 27001:

• Plantillas de políticas alineadas con ISO 27001 escritas específicamente para empresas SaaS, cubriendo cada control del Annex A con lenguaje que refleja operaciones nativas de la nube — sin referencias a copias de seguridad en cinta ni salas de servidores físicos
• Mapeo automatizado de políticas a controles que rastrea cada control del Annex A en su Declaración de Aplicabilidad a la política que lo gobierna, identificando brechas antes de que lo haga su auditor
• Gestión integrada del ciclo de vida de políticas con control de versiones, flujos de trabajo de aprobación digital, seguimiento de acuses de recibo de empleados y recordatorios de revisión automatizados que aseguran que sus políticas nunca se vuelvan obsoletas

Comience con GRCTrail

Guías Relacionadas

• ¿Qué es ISO 27001? Una Guía Práctica para Empresas SaaS
• Requisitos de ISO 27001: Comprendiendo las Cláusulas 4-10
• Controles del Annex A de ISO 27001: La Guía Completa
• Lista de Verificación de Certificación ISO 27001
• Control de Acceso ISO 27001: Requisitos, Controles e Implementación SaaS
• Políticas y Procedimientos de SOC 2: Lo que Necesita Documentar