Cómo redactar una política de seguridad de la información (cláusula 5.2 de ISO 27001)

La política de seguridad de la información que exige la cláusula 5.2 de ISO 27001 es un único documento de alto nivel establecido por la alta dirección. Declara a qué se compromete la organización y por qué — y es deliberadamente breve. Una o dos páginas es lo normal. Diez son señal de que se ha colado algo que corresponde a una política específica.

Este es el documento que más a menudo se confunde con todo el conjunto de políticas. Si lo que necesitas de verdad es el conjunto de políticas — uso aceptable, control de accesos, respuesta a incidentes y las demás —, empieza por el conjunto mínimo de políticas mapeado a los Trust Services Criteria o por nuestras nueve políticas internas de empresa con plantillas. Este artículo trata de la única política que está por encima de todas ellas.

Qué exige la cláusula 5.2

La norma es aquí inusualmente concreta. La alta dirección debe establecer una política de seguridad de la información que:

• Sea apropiada al propósito de la organización. Una empresa de pagos y un estudio de diseño no deberían tener la misma política. El texto genérico es la forma más rápida de dejar claro que nadie del equipo directivo se implicó.
• Incluya objetivos de seguridad de la información, o proporcione el marco de referencia para establecerlos. O bien declaras los objetivos, o bien declaras cómo y quién los fija y los revisa. La mayoría de las organizaciones opta por el marco de referencia y mantiene los objetivos en un documento aparte que se actualiza con más frecuencia.
• Incluya el compromiso de cumplir los requisitos aplicables relacionados con la seguridad de la información: legales, reglamentarios y contractuales.
• Incluya el compromiso con la mejora continua del sistema de gestión de la seguridad de la información.

Y la propia política debe:

• Estar disponible como información documentada
• Comunicarse dentro de la organización
• Estar disponible para las partes interesadas, según corresponda

Esas tres últimas líneas son donde de verdad se tuercen las auditorías. Redactar la política es la mitad fácil; demostrar que llegó a la gente es la mitad que los equipos olvidan. Más sobre eso abajo.

Un esqueleto sección por sección

Una estructura que satisface la cláusula 5.2 sin engordar:

1. Propósito y alcance — un párrafo sobre por qué existe la política y a qué aplica, alineado con tu declaración de alcance del SGSI. No repitas el alcance; remite a él.
2. Declaración de compromiso — qué se compromete a proteger la organización, en lenguaje llano: la confidencialidad, la integridad y la disponibilidad de la información de clientes y de la empresa.
3. Objetivos o el marco para establecerlos — o los propios objetivos, o una frase que explique que los objetivos se fijan anualmente en la revisión por la dirección y se registran como información documentada.
4. Compromiso con los requisitos aplicables — obligaciones legales, reglamentarias y contractuales relevantes para la seguridad de la información.
5. Compromiso con la mejora continua — del SGSI, remitiendo en la práctica a la cláusula 10 aunque no la cites por número.
6. Roles y responsabilidades — quién es responsable del SGSI, quién aprueba las políticas, qué se espera de cada empleado. Usa roles con nombre en lugar de personas con nombre, para que el documento no cambie con cada contratación.
7. Políticas de apoyo — una lista de las políticas específicas que dependen de esta, para que quien la lea sepa dónde está el detalle.
8. Consecuencias del incumplimiento — una declaración breve y honesta, coherente con tus condiciones de empleo.
9. Aprobación y revisión — quién la aprobó, cuándo y con qué periodicidad se revisa.

Qué no debe ir en ella

La forma más clara de mantener corto este documento es ser estricto con lo que va en otra parte. El detalle operativo corresponde a las políticas específicas y a los procedimientos:

• Longitud de contraseñas y detalles del MFA → política de control de accesos
• Qué puede instalar un empleado en su portátil → política de uso aceptable
• Niveles de severidad y rutas de escalado → plan de respuesta a incidentes
• Calendarios de copias de seguridad y periodos de retención → documentación de copias de seguridad y continuidad
• Cómo se evalúa a los proveedores → política de seguridad de proveedores

La razón no es el orden. Es la velocidad de cambio. La política de alto nivel debería ser lo bastante estable como para que la alta dirección la reapruebe una vez al año sin leerse un diff. Todo lo que esperes que cambie cada trimestre tiene que vivir en un sitio que pueda cambiar cada trimestre sin un ciclo de revisión por la dirección. Para gestionar ese ciclo de vida en todo el conjunto, mira la gestión de políticas internas.

La prueba que merece la pena aplicar

Dale la política a un fundador o a un directivo que no la haya escrito, espera una semana y pídele que resuma a qué se compromete la empresa. Si es capaz — con precisión y sin el documento delante —, es apropiada al propósito de la organización en el sentido que quiere decir la cláusula 5.2. Si se encoge de hombros, lo que tienes es una plantilla con tu logo, y el auditor que entreviste a esa misma persona llegará a la misma conclusión.

No es una técnica de auditoría hipotética. Los auditores sí entrevistan al personal, y aquello de que "la alta dirección demuestra liderazgo y compromiso" se evalúa en parte por si quienes están arriba saben hablar de su propia política. Mira la cláusula 5 sobre liderazgo para ver qué más entra en ese apartado.

Comunicarla — y demostrar que lo hiciste

"Comunicada dentro de la organización" es un requisito, y un auditor te pedirá evidencias. Publicar el documento en una unidad compartida no es comunicación; es disponibilidad. Son dos requisitos separados en la cláusula por algo.

Lo que sirve como evidencia:

• Registros de aceptación — un registro por empleado de que leyó la versión vigente, con fecha y la versión que aceptó.
• Cobertura en el onboarding — la política forma parte de la incorporación, con un registro por cada persona nueva.
• Nueva aceptación cuando hay cambios materiales — cuando la política cambia de forma sustantiva, la gente acepta la versión nueva en lugar de que la antigua siga silenciosamente "aceptada".
• Disponibilidad para las partes interesadas — cuando corresponda, un resumen público o una versión que se entrega a clientes bajo NDA. Un centro de confianza es una forma habitual de cubrir esto sin publicar detalle interno.

El control de versiones importa aquí más de lo que los equipos esperan. Si las aceptaciones no están ligadas a una versión, no puedes demostrar quién aceptó qué, y el registro deja de ser evidencia.

Aprobación y periodicidad de revisión

La política la aprueba la alta dirección: en una startup, un fundador o el CTO, quien de verdad tenga autoridad sobre el SGSI. La revisión anual es la periodicidad habitual, normalmente integrada en la revisión por la dirección de la cláusula 9.3, más una revisión fuera de ciclo cuando cambia algo material: una nueva obligación regulatoria, un incidente significativo, un cambio de alcance o una adquisición.

Deja registro de la aprobación. Una política cuyo historial de aprobación es el metadato de "última modificación" de un editor de documentos es una evidencia pobre de que la alta dirección haya establecido nada.

La conclusión

Escribe una o dos páginas que suenen a tu empresa, cubre las cuatro cosas que nombra la cláusula 5.2 y remite a las políticas específicas donde está el detalle. Y dedica el esfuerzo que te quede a la parte que de verdad tumba auditorías: conseguir que se acepte, se versione y se revise con una periodicidad que puedas demostrar.

Siguiente: la cláusula 5 al completo, el conjunto mínimo de políticas para lo que va por debajo de esta, o el recorrido completo por las cláusulas 4–10.