ISO 27001 regula los roles de seguridad a través de dos disposiciones: la Cláusula 5.3, que exige que la alta dirección asigne y comunique responsabilidades y autoridades, y el control 5.2 del Anexo A, que requiere definir y asignar roles de seguridad de la información en toda la organización. Juntas le obligan a identificar quién es propietario de cada control, documentarlo y demostrar que el personal conoce sus funciones. Esa obligación se aplica independientemente del tamaño de la empresa, el sector o el número de funciones que desempeñe una misma persona.
Resumen ejecutivo:
- La titularidad documentada de los roles debe estar alineada con los riesgos reales y las necesidades operativas, independientemente de los títulos de los puestos o del tamaño de la organización.
- Las organizaciones pequeñas suelen combinar roles como el de responsable del ISMS y el de responsable de TI, pero deben registrar controles compensatorios para mantener la independencia.
- Los auditores verifican que los niveles de responsabilidad, rendición de cuentas y autoridad estén claramente asignados, comunicados y respaldados con evidencia, como registros de formación y de aprobación.
- Las descripciones de roles deben incluir propósito, responsabilidades, autoridad, competencia y almacenamiento de evidencias, utilizando etiquetas basadas en el rol en lugar de nombres individuales.
- La mayoría de los fallos en auditoría se deben a matrices RACI desactualizadas, roles asignados a personas en lugar de puestos, y falta de responsabilidades documentadas para todo el personal.
Tabla de Contenidos
- Qué Exige Realmente ISO 27001 en Materia de Roles
- Roles Fundamentales de ISO 27001 y sus Responsabilidades
- Documentación de Roles: Matrices RACI y Descripciones de Puestos
- Demostración de Competencia para Cada Rol
- ¿Puede una Persona Desempeñar Varios Roles?
- Plantillas de Roles y un Ejemplo de RACI Adaptable
- Convertir la Cobertura de Roles en un Plan de Personal
- Errores Frecuentes de los Implementadores en Materia de Roles
- Fuentes
Qué Exige Realmente ISO 27001 en Materia de Roles
La Cláusula 5.3 traslada la responsabilidad directamente a la alta dirección. El liderazgo debe garantizar que las responsabilidades y autoridades en materia de roles de seguridad se asignen y comuniquen en toda la organización, y debe designar a alguien responsable de informar sobre el desempeño del ISMS. Este segundo aspecto genera problemas a muchos implementadores: la cláusula no trata únicamente de asignar tareas, sino de crear una línea de reporte hacia el liderazgo. Alguien tiene que informar a la alta dirección sobre cómo está funcionando realmente el ISMS, no solo confirmar que existe.
El Anexo A 5.2 actúa en paralelo a la Cláusula 5.3, pero se centra en la capa de controles. Exige que las organizaciones definan y asignen roles y responsabilidades de seguridad de la información conforme a sus propias necesidades operativas, no a partir de una plantilla genérica. Un auditor que revise este control no está comprobando si usted copió una lista de roles de una guía. Está verificando si los roles que usted definió responden realmente a los riesgos y procesos que su organización gestiona.
Los auditores evalúan tres aspectos: asignación (¿existe un responsable documentado para cada responsabilidad?), comunicación (¿las personas en esos roles saben que los ocupan?) y autoridad (¿puede el titular del rol tomar las decisiones que este requiere, o es un título sin poder real?). Un propietario de control que no puede aprobar un presupuesto de remediación no es realmente un propietario de control.
Cabe destacar una flexibilidad importante: ISO 27001 no impone una denominación específica para el rol. Puede llamar a alguien "Coordinador de Seguridad de la Información", "Responsable del ISMS" o "Director de Cumplimiento" y satisfacer la norma de igual forma, siempre que la responsabilidad subyacente esté documentada y comprendida. Lo que importa es el contenido, no el título en una tarjeta de visita.
Roles Fundamentales de ISO 27001 y sus Responsabilidades
Todo ISMS necesita cubrir un conjunto reducido de tipos de roles, tanto si se trata de una startup de 12 personas como de una multinacional. A continuación se describe lo que hace cada uno en el día a día.
Alta dirección. Este no es un rol ceremonial. El liderazgo establece la política de seguridad de la información, acepta formalmente el riesgo residual que supera el apetito de riesgo de la organización y asigna el presupuesto y el tiempo de personal que el ISMS necesita para funcionar. También revisa el desempeño del ISMS con una periodicidad definida, habitualmente mediante una reunión de revisión por la dirección, y esa revisión debe generar decisiones documentadas, no solo actas de reunión que indiquen "se debatió."
Responsable del ISMS o CISO. Este rol, a veces denominado Responsable de Seguridad de la Información, es el propietario del conjunto de documentación del ISMS: la Declaración de Aplicabilidad, el plan de tratamiento de riesgos y las políticas internas. Dirige o coordina las evaluaciones de riesgos, impulsa la implementación de controles en todos los departamentos e informa del estado a la alta dirección. En empresas pequeñas, esta persona suele encargarse también de las operaciones de seguridad cotidianas. En las más grandes, es un puesto dedicado con un equipo a su cargo.
Propietarios de activos frente a propietarios de sistemas. Estos roles se confunden constantemente, y los auditores lo detectan. Un propietario de activo es responsable de las decisiones de clasificación y protección de un activo de información concreto, como registros de clientes o repositorios de código fuente. Un propietario de sistema es responsable de la configuración técnica, los controles de acceso y la seguridad operativa del sistema que procesa ese activo. Una base de datos puede tener un propietario de negocio (propietario del activo) que decide quién puede consultar los datos personales de clientes, y un propietario de TI (propietario del sistema) que configura las reglas del cortafuegos y el calendario de parches. Esta distinción cobra mayor importancia en organizaciones donde el negocio y las áreas de TI operan como funciones verdaderamente separadas.
Propietarios de riesgos y propietarios de controles. Un propietario de riesgo decide cómo se trata un riesgo determinado: aceptar, mitigar, transferir o evitar. Un propietario de control es responsable de garantizar que el control específico vinculado a ese riesgo se implemente y se mantenga operativo. Pueden ser la misma persona, pero en riesgos transversales (por ejemplo, un riesgo de proveedor que afecta a compras, legal y TI) suelen separarse para que la responsabilidad no se diluya entre departamentos.
Auditoría interna. La auditoría interna debe mantenerse independiente de las operaciones que revisa, razón por la cual la persona que audita un control no puede ser la misma que lo opera. Los auditores internos necesitan conocimiento práctico de los requisitos de auditoría de ISO 27001, un plan y un calendario de auditoría documentados, y una línea de reporte que permita que los hallazgos lleguen a la alta dirección sin ser filtrados por el departamento auditado.
Todo el personal. Cada empleado tiene una responsabilidad básica en materia de seguridad: completar la formación asignada, notificar con prontitud los incidentes sospechosos y cumplir las políticas de uso aceptable y tratamiento de datos aplicables a su rol. Esta es la categoría de roles más amplia en número de personas y la que con más frecuencia se documenta deficientemente, aunque el error humano sigue siendo una de las principales causas de incidentes de seguridad, lo que convierte la responsabilidad a nivel del personal en uno de los roles con mayor impacto potencial si se gestiona correctamente.
Un resumen rápido de quién es responsable de qué:
- Alta dirección: aprobación de la política, aceptación de riesgos, asignación de recursos, revisión del desempeño.
- Responsable del ISMS / CISO: documentación, coordinación de la evaluación de riesgos, reporte ascendente.
- Propietario del activo: clasificación y protección de un activo de información específico.
- Propietario del sistema: configuración técnica y seguridad operativa de los sistemas que albergan ese activo.
- Propietario del riesgo: decisiones de tratamiento para los riesgos asignados.
- Propietario del control: implementación y operación continua de un control específico.
- Auditor interno: verificación independiente, planificación de auditorías, reporte de hallazgos.
- Todo el personal: finalización de formaciones, notificación de incidentes, cumplimiento de políticas.
Documentación de Roles: Matrices RACI y Descripciones de Puestos
Un rol que solo existe en la memoria de alguien no existe a efectos de auditoría. Debe constar por escrito, asociado a un puesto en lugar de a una persona, para que el documento sobreviva a la rotación de personal.
- Enumere sus procesos y controles. Parta de su Declaración de Aplicabilidad y de sus procesos operativos clave, y descienda hasta una lista granular, no "seguridad de TI" sino "gestión de parches en endpoints", "revisión de incorporación de proveedores", etcétera.
- Asigne Responsable, Aprobador, Consultado e Informado para cada uno. Este es el paso RACI, y la guía de profesionales recomienda sistemáticamente este formato porque obliga a designar exactamente un aprobador por elemento de la lista, lo que elimina el fallo del tipo "todos pensaban que otro era el responsable".
Las descripciones de puestos y las entradas del manual del ISMS deben incluir el propósito del rol, sus responsabilidades específicas, la autoridad que conlleva (límites de aprobación presupuestaria, derechos de autorización), la competencia requerida para ocuparlo y el lugar donde se almacenan los registros de su actividad.
Los auditores solicitarán evidencia de que el RACI refleja la realidad: registros de comunicación que demuestren que se informó a las personas de su asignación, aprobación de la dirección sobre la propia matriz, registros de formación vinculados a cada rol y registros de aceptación de riesgos firmados por el propietario real del riesgo y no por un delegado sin autoridad documentada.
Consejo práctico: Mantenga su matriz RACI y su lista de titulares en dos archivos separados. Actualice la lista de titulares el mismo día en que alguien cambie de puesto; actualice la matriz RACI solo cuando cambie la responsabilidad en sí. Mezclar ambas es la razón más frecuente por la que la evidencia de auditoría queda desactualizada.
Demostración de Competencia para Cada Rol
Asignar un rol no es suficiente. Necesita evidencia de que la persona que lo ocupa puede desempeñarlo realmente. Los auditores aceptan una combinación de credenciales formales y evidencia en el puesto de trabajo: certificaciones como CISSP o CISM para roles de liderazgo en seguridad, cualificaciones de implementador líder o auditor líder de ISO 27001 para responsables del ISMS y auditores internos, y experiencia práctica documentada para roles operativos más específicos como los propietarios de controles.
Establezca formación específica por rol con un ciclo de actualización, anual como mínimo para la concienciación sobre políticas, y con mayor frecuencia para roles técnicos que gestionan control de acceso o respuesta a incidentes. Documente cada carencia identificada y la acción correctiva adoptada. Las ofertas de empleo para responsables de implementación de ISO 27001 suelen describir plazos de proyecto de certificación de seis a nueve meses, lo que le ofrece una referencia realista sobre el margen de tiempo que necesita un rol recién asignado antes de estar listo para una auditoría.
¿Puede una Persona Desempeñar Varios Roles?
Sí, y en organizaciones pequeñas es habitual. Un responsable del ISMS que también ejerce como responsable de TI es una combinación frecuente y justificable, siempre que el riesgo de segregación de funciones quede documentado y no ignorado.
La línea que trazan los auditores son las combinaciones sensibles a la independencia. Un auditor interno que también opera los controles que debe revisar es el ejemplo problemático clásico, ya que elimina la objetividad que justifica la existencia del rol. Un propietario de control que aprueba sus propias excepciones de riesgo incurre en el mismo problema.
Cuando la consolidación es inevitable, registre un control compensatorio: un segundo revisor independiente, una verificación trimestral por parte de la dirección sobre las decisiones del rol combinado, o un auditor externo que intervenga en el área específica donde no es posible mantener la independencia interna. Documente el historial de aprobación de ese control compensatorio de la misma forma que documentaría la propia asignación del rol.
Plantillas de Roles y un Ejemplo de RACI Adaptable
Cada descripción de rol debe contemplar cinco elementos: propósito (por qué existe el rol), responsabilidades (qué hace), autoridad (qué puede aprobar o bloquear), competencia (qué cualifica a alguien para ocuparlo) y registros (dónde se almacena la evidencia de su actividad).
En las listas de verificación de auditoría, la mayoría de los roles necesitan entre tres y cinco puntos de verificación: una asignación documentada, evidencia de comunicación al titular del rol, al menos un registro del ejercicio del rol, evidencia de formación o competencia, y una referencia a la revisión por la dirección que demuestre que el resultado del rol llegó al liderazgo.
| Área de control | Responsable | Aprobador | Consultado | Informado |
|---|---|---|---|---|
| Revisión de accesos | Propietario del sistema | Responsable del ISMS | Responsable de TI | Auditoría interna |
| Plan de tratamiento de riesgos | Propietario del riesgo | Alta dirección | Responsable del ISMS | Propietarios de controles |
| Respuesta a incidentes | Responsable de incidentes | Responsable del ISMS | Legal, RRHH | Todo el personal |
Esta estructura funciona para cualquier conjunto de controles una vez sustituidos los nombres de sus propios procesos, incluidos los contemplados en una lista de verificación de certificación completa.
Convertir la Cobertura de Roles en un Plan de Personal
Definir roles sobre el papel es un ejercicio. Calcular cuántas personas, horas y recursos económicos cuesta realmente esa cobertura de roles es otro, y es donde la mayoría de los implementadores subestiman el proyecto. Las herramientas de preparación pueden tomar el panorama de roles y madurez que acaba de construir y convertirlo en una estimación concreta del esfuerzo.
Algunas calculadoras ajustan su resultado en función de variables que se relacionan directamente con la cobertura de roles:
- El tamaño de la empresa, que determina cuántas personas necesitan formación específica por rol frente a un único responsable del ISMS combinado.
- El sector, dado que los sectores regulados suelen requerir una segregación más profunda entre propietarios de riesgos y propietarios de controles.
- La madurez actual en seguridad a través de los cuatro temas de control del Anexo A que evalúa, lo que determina qué parte de la estructura de roles ya existe y qué parte hay que construir desde cero.
El resultado se traduce directamente en términos de planificación: un número sugerido de roles para su tamaño y sector, un presupuesto estimado de formación vinculado a las certificaciones y registros de competencia que esos roles requieren, y un cronograma desglosado en fases de implementación en formato Gantt. Puede guardar un escenario, ajustar una variable como el número de empleados y comparar el cambio de personal resultante en paralelo, y luego exportar la estimación en PDF para las reuniones de planificación.
Consejo práctico: Realice la verificación de preparación gratuita de 2 minutos antes de su primera revisión por la dirección. Le proporciona una estimación aproximada de las carencias en la cobertura de roles que puede presentar en la reunión en lugar de llegar con una solicitud de presupuesto sin datos concretos.
Errores Frecuentes de los Implementadores en Materia de Roles
Los mismos tres errores aparecen en casi todos los hallazgos de auditoría fallidos sobre roles. Una matriz RACI que no se ha actualizado desde que se redactó hace dos años. Responsabilidades escritas asociadas al nombre de una persona en lugar de a un puesto, de modo que el documento queda inutilizable en el momento en que alguien se va. Y registros de formación que existen para el responsable del ISMS pero no para nadie más, dejando el rol de "todo el personal" sin documentar a pesar de que concentra la mayor parte del riesgo derivado del error humano.
Corrija primero esos tres aspectos. Son los que menos cuestan de corregir y los que generan más hallazgos. A continuación, realice una evaluación de preparación para conocer en qué situación real se encuentra su estructura de roles respecto al referencial de su sector antes de que se lo indique un auditor externo.
— Martin
Fuentes
- Página de normas ISO (ISO)
- ISO 27001 Anexo A 5.2 Roles y Responsabilidades + Plantilla (HighTable)
- Roles y responsabilidades de seguridad ISO 27001 (Risk3Sixty)
- IAPP: Los datos indican que el error humano es la causa principal de brechas e incidentes