SekitCrosswalk
ISO/IEC 27001:2022 · destino de mapeo derivado

A.5.16Identity management

Manage digital identities across their full lifecycle, from creation to removal, so every account maps to a known person or service. Stale or shared identities are a frequent source of breaches.

Mapeado desde el Sekit CSF

Los controles de Sekit que cubren este requisito, lente a lente.

RCF-0061Identity lifecycle · PolíticaapoyaEl control de Ciclo de vida de identidad de Sekit documenta cómo se solicitan, crean, modifican y eliminan las cuentas en todos sus sistemas, el compromiso escrito detrás de A.5.16; la aplicación técnica y el procedimiento de altas, cambios y bajas se mapean aparte.RCF-0062Identity lifecycle · ProcesoapoyaEjecutar la incorporación y la baja desde una lista repetible es lo que evita que la regla de ciclo de vida de A.5.16 dependa de que alguien recuerde cada paso para cada nueva contratación.RCF-0063Identity lifecycle · TécnicaapoyaConectar los sistemas para que una acción de deshabilitación en la plataforma central de identidad revoque el acceso en todas partes elimina los pasos manuales que suelen hacer fallar en la práctica las promesas de ciclo de vida de A.5.16.RCF-0073SSO & federation · PolíticaapoyaExigir que las aplicaciones de negocio inicien sesión mediante el proveedor de identidad central es lo que hace que cada cuenta sea rastreable a una persona conocida, el mapeo que pide A.5.16.RCF-0074SSO & federation · ProcesoapoyaConectar una nueva aplicación al proveedor de identidad como un paso rutinario de adopción hace que herede el ciclo de vida de la cuenta desde el primer día, coincidiendo con el alcance de ciclo completo de A.5.16.RCF-0075SSO & federation · TécnicaapoyaAutenticar las aplicaciones de negocio críticas mediante el proveedor de identidad central significa que cada cuenta ahí está ligada a una identidad conocida, el mapeo que exige A.5.16.RCF-0088JML (joiner-mover-leaver) · PolíticaapoyaEl procedimiento de altas, cambios y bajas de Sekit nombra quién dispara cada evento y el plazo para revocar el acceso de quien se va, pero escribirlo no lo ejecuta: la ejecución automatizada que también necesita A.5.16 se mapea aparte como control técnico.RCF-0090JML (joiner-mover-leaver) · TécnicaapoyaConectar RR. HH. o el directorio de personal al proveedor de identidad para que los eventos de ciclo de vida se disparen automáticamente cierra el vacío de la cadena manual del que provienen las cuentas obsoletas o huérfanas, el riesgo central de A.5.16.RCF-0327Offboarding vendors · TécnicaapoyaAutomatizar la revocación de acceso de proveedores y confirmar técnicamente que no queda nada residual aplica la disciplina de ciclo de vida de A.5.16 a identidades que no son empleados.RCF-0336Cloud IAM · TécnicaapoyaExigir MFA, permisos basados en roles y restricciones condicionales en la nube es gestión de identidad aplicada técnicamente a las cuentas en la nube, los sistemas que A.5.16 pide cubrir.

Correspondencias en NIST CSF 2.0

Alcanzadas a través de los controles del Sekit CSF que ambos mapean: un mapeo, no una equivalencia formal.

Correspondencias en Cyber Essentials

Evidencia que demuestra este control

Lo que pide un auditor, o el motor de evidencias de Sekit.

Procedimiento de altas, cambios y bajas (onboarding/offboarding)
El proceso que sigue la empresa cuando alguien entra, cambia de puesto o se va: cómo se le dan y se le quitan los accesos y equipos.
Del catálogo de evidencias de Sekit

En la práctica

La versión práctica de este control es una identidad por persona, conectada mediante un proveedor de identidad central, con el procedimiento de altas, cambios y bajas como el documento operativo que los auditores piden por nombre. Lo que falla en empresas reales es el paso manual del medio: RR. HH. le avisa al gerente, el gerente le avisa a TI, y en algún punto de esa cadena la cuenta de quien se va sigue activa por semanas porque nadie cerró el ciclo. Los auditores prueban esto directamente pidiendo un listado de cuentas deshabilitadas en el último trimestre y comparando fechas con las fechas reales de salida según los registros de RR. HH.

Brechas habituales

El procedimiento de altas, cambios y bajas existe solo en papel: las cuentas de baja siguen activas de una a tres semanas tras la salida porque el traspaso entre RR. HH. y TI es manual.
Las cuentas de servicio y los buzones compartidos no están ligados a ninguna persona identificada, así que nadie puede decir quién es responsable si alguno se ve comprometido.
Un evento de cambio de rol interno solo elimina el acceso anterior cuando alguien lo nota, en lugar de ser un paso automático del traspaso.

Preguntas que hará tu auditor

¿Cómo se crea una cuenta, y cómo se vincula a una persona real?
Recorre el paso de incorporación del procedimiento de altas, cambios y bajas, mostrando la cuenta creada a partir de un registro verificado de RR. HH., no una solicitud de texto libre.
¿Qué pasa con una cuenta el día que alguien se va?
Señala el paso de baja del procedimiento y el plazo que fija para deshabilitar el acceso, idealmente el mismo día, más evidencia de fechas recientes de salida contrastadas con las fechas de deshabilitación.
¿Hay cuentas compartidas o genéricas, y cómo se controlan?
Identifica los inicios de sesión compartidos que aún existen, la razón de negocio de cada uno y el control compensatorio, como acceso registrado, aplicado a cada uno.

Dónde lo exige la regulación

NIS2 art. 11.5 (identificación) exige el mismo mapeo de cada cuenta a una persona o servicio conocido.
ENS op.acc.1 (Identificación) es la línea base equivalente de España para la gestión de identidad en todo su ciclo de vida.

Controles relacionados

Vía el tema compartido del Sekit CSF, no el índice del propio marco.

Pregúntale a Sekura: «¿Qué evidencia demuestra A.5.16?»
También vía MCP, gratis con cuenta