PAM y cuentas break-glass para ISO 27001 en 2026

A las 02:14 de un domingo por la mañana, el responsable de gestión del incidente recibe el mensaje que todo CISO teme: “La autenticación de producción está fallando. La consola de administración no está accesible. La conmutación por error de la base de datos está bloqueada”.

El ingeniero de nube de guardia puede ver el problema, pero no puede corregirlo. Su rol privilegiado habitual depende del mismo proveedor de identidad que ahora está degradado. El responsable de operaciones solicita la credencial de administrador de emergencia. El responsable de cumplimiento pregunta si la cuenta break-glass se ha probado alguna vez. El delegado de protección de datos (DPO) pregunta si el acceso a la base de datos de producción puede exponer datos personales. El CISO formula la pregunta que determina si esto se convertirá en una recuperación controlada o en una pesadilla de auditoría:

“¿Podemos demostrar quién utilizó el acceso de emergencia, por qué, qué hizo y que la cuenta se restableció después?”

Otra organización puede enfrentarse al mismo problema en una sala más silenciosa. El CISO de una fintech se sienta frente a auditores externos después de una configuración incorrecta de una base de datos en la nube. El incidente se corrigió rápidamente, pero la causa raíz no era tranquilizadora. Un desarrollador de un tercero tenía privilegios administrativos permanentes. Cuando el administrador principal no estuvo disponible, el desarrollador utilizó una cuenta break-glass basada en una contraseña compartida almacenada en una nota “segura” disponible para el equipo DevOps.

Los auditores no se centraron solo en la configuración incorrecta. Preguntaron si el acceso estaba limitado en el tiempo, si existía rendición de cuentas individual, si los comandos se registraban, si los datos personales estaban protegidos conforme al artículo 32 del RGPD de la UE, si se cumplían las obligaciones de gestión del riesgo de las TIC de DORA y si las expectativas de higiene cibernética de NIS2 eran demostrables.

Ese es el verdadero punto de presión de la gestión de accesos privilegiados y de las cuentas break-glass en 2026. PAM ya no es un proyecto de seguridad de identidad de nicho. Es el punto en el que convergen el ransomware, la exposición de la nube, el riesgo de proveedores, la protección de datos, la resiliencia operativa y las evidencias de auditoría.

El acceso privilegiado es donde los atacantes intentan ganar. El acceso break-glass es donde los defensores intentan recuperarse. Ambos dependen de la misma capacidad peligrosa: acceso elevado que puede eludir controles, cambiar configuraciones, leer datos sensibles, rotar claves, deshabilitar el registro de eventos, restaurar copias de seguridad, desplegar código o destruir evidencias.

La posición práctica de Clarysec es sencilla: el acceso de emergencia es necesario, pero el acceso de emergencia no gestionado es riesgo no gestionado. La respuesta correcta no es “sin cuentas break-glass”. La respuesta correcta es un modelo gobernado de gestión de accesos privilegiados con inventario, aprobación, límites temporales, autenticación fuerte, registro de sesiones, revisión posterior al uso, restablecimiento de credenciales y evidencias de auditoría.

Por qué el acceso privilegiado es una cuestión de cumplimiento a nivel del consejo de administración

En entornos de menor madurez, el acceso privilegiado suele tratarse como una tarea de administración de TI. Alguien necesita derechos de administrador, se abre un ticket, se concede un rol y la organización continúa. Ese modelo no resiste el ransomware moderno, la infraestructura nativa de la nube, la responsabilidad proactiva de NIS2, la resiliencia operativa de DORA ni el escrutinio de brechas del RGPD de la UE.

La Directiva NIS2 sitúa la gobernanza de la ciberseguridad en el consejo de administración. El artículo 20 exige que los órganos de dirección de las entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implantación y reciban formación en ciberseguridad. El artículo 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidas el análisis de riesgos, la gestión de incidentes, la continuidad del negocio, la seguridad de la cadena de suministro, la eficacia del control, la higiene cibernética, la seguridad de los recursos humanos, el control de acceso, la gestión de activos y la autenticación multifactor o autenticación continua cuando proceda.

Para proveedores SaaS, proveedores de servicios gestionados, proveedores de seguridad gestionada, servicios en la nube, centros de datos y otras organizaciones de infraestructura digital, la aplicabilidad de NIS2 depende del sector, tamaño, función, impacto transfronterizo y establecimiento en la UE. La lección operativa es directa: el control de acceso ya no está enterrado en un anexo técnico. Forma parte de la base de higiene cibernética que la dirección debe aprobar, supervisar y corregir.

Para las entidades financieras, el Reglamento de Resiliencia Operativa Digital cambia el lenguaje, pero no el riesgo subyacente. DORA se aplica desde el 17 de enero de 2025 y establece un marco uniforme para la gestión del riesgo de las TIC, la notificación de incidentes importantes relacionados con las TIC, las pruebas de resiliencia operativa digital y la gestión del riesgo de terceros de TIC. El artículo 5 exige mecanismos de gobernanza y control para el riesgo de las TIC, con el órgano de dirección definiendo, aprobando, supervisando y asumiendo la responsabilidad de dichos mecanismos. El artículo 6 exige un marco documentado de gestión del riesgo de las TIC con políticas, procedimientos, protocolos y herramientas para proteger los activos de TIC. El artículo 17 exige un proceso de gestión de incidentes relacionados con las TIC que detecte, registre, clasifique, escale y restablezca operaciones seguras.

El RGPD de la UE añade la perspectiva de privacidad y responsabilidad proactiva. El artículo 5(1)(f) exige que los datos personales se traten con integridad y confidencialidad. El artículo 5(2) exige responsabilidad proactiva. El artículo 25 exige protección de datos desde el diseño y por defecto. El artículo 32 exige medidas técnicas y organizativas adecuadas para la seguridad del tratamiento. Si un usuario privilegiado puede exportar registros de clientes, acceder a datos de categorías especiales, deshabilitar registros de auditoría o cambiar ajustes de conservación sin revisión, la organización no solo ha cometido un error de IAM. Puede no ser capaz de demostrar una seguridad adecuada.

ISO/IEC 27001:2022 es la columna vertebral del sistema de gestión que permite tratar estas obligaciones mediante un programa integrado. La cláusula 4.2 exige que la organización comprenda a las partes interesadas y sus requisitos, incluidas las obligaciones legales, regulatorias y contractuales. La cláusula 5.1 exige liderazgo y compromiso. La cláusula 6.1.2 exige evaluación de riesgos de seguridad de la información. La cláusula 6.1.3 exige tratamiento de riesgos. La cláusula 8 exige planificación y control operacional.

Para el acceso privilegiado, esto desplaza la conversación de “¿qué herramienta PAM debemos comprar?” a “¿qué riesgos estamos tratando, qué controles se seleccionan, quién es su propietario, cómo se operan y qué evidencias demuestran que funcionan?”

PAM no es un único control, es una cadena de evidencias

Una herramienta PAM puede custodiar contraseñas en una bóveda, intermediar sesiones, registrar pulsaciones de teclado, rotar credenciales y aplicar acceso justo a tiempo. Esas capacidades importan. Pero si la organización no ha definido funciones privilegiadas, aprobado el acceso de emergencia, mapeado el acceso a los activos, revisado los derechos, protegido los registros y formado a los administradores, la herramienta se convierte en un control parcial con escasa capacidad de defensa en auditoría.

La forma más útil de gobernar el acceso privilegiado es pensar en resultados de control, no en nombres de herramientas.

Zenith Controls: The Cross-Compliance Guide Zenith Controls trata el control ISO/IEC 27002:2022 8.2, derechos de acceso privilegiado, como el centro de gravedad de PAM. Clasifica este control como preventivo, de apoyo a la confidencialidad, integridad y disponibilidad, alineado con el concepto de ciberseguridad Protect, la capacidad operativa de gestión de identidades y accesos y el dominio de seguridad Protección.

El control 8.2 es potente porque conecta con los controles circundantes que hacen auditable el acceso privilegiado:

Por eso un auditor rara vez se detiene en la pregunta: “¿Tienen un sistema PAM?” Las preguntas de auditoría más sólidas son: ¿Tienen un inventario de cuentas privilegiadas? ¿Están aprobados los roles privilegiados? ¿Los derechos están limitados en el tiempo? ¿Las credenciales de emergencia están protegidas? ¿Pueden demostrar quién las utilizó? ¿Se registran los comandos? ¿Están incluidos los administradores de proveedores? ¿Se revisan los derechos de acceso? ¿Se restablecieron las credenciales? ¿Se aceptaron las excepciones de riesgo?

El mapeo de derechos de acceso de Zenith Controls lo expresa directamente: la gestión de derechos de acceso operacionaliza principios de control de acceso como mínimo privilegio, necesidad de conocer y autorización, mientras que las cuentas privilegiadas requieren un escrutinio especial y una revocación inmediata cuando ya no son necesarias.

Requisitos de política para un acceso break-glass confiable

Una cuenta break-glass no es una contraseña de administrador compartida en un sobre sellado. En 2026, ese modelo es demasiado débil para la nube, fintech, SaaS, sanidad, servicios gestionados y operaciones digitales reguladas.

Un modelo break-glass defendible necesita siete reglas mínimas de política:

1. La cuenta debe estar documentada.
2. La cuenta debe estar aprobada.
3. El uso debe ser atribuible de forma única cuando sea técnicamente posible.
4. El uso debe limitarse a emergencias reales.
5. El uso debe registrarse y revisarse.
6. Las credenciales o factores de autenticación deben restablecerse o rotarse después del uso.
7. La cuenta debe probarse e incluirse en el alcance de auditoría.

La biblioteca de políticas de Clarysec convierte estos principios en lenguaje de gobernanza utilizable.

La Política de gestión de cuentas de usuario y privilegios para pymes Política de gestión de cuentas de usuario y privilegios - pyme establece:

“El acceso de emergencia (por ejemplo, cuentas de administrador “break-glass”) debe estar claramente documentado, protegido y utilizarse solo cuando sea absolutamente necesario.”

De la sección “Tratamiento de riesgos y excepciones”, cláusula de política 7.3.1.

La misma política para pymes continúa:

“Dichas cuentas deben registrarse, revisarse después de su uso y restablecerse después de cada evento de emergencia.”

De la sección “Tratamiento de riesgos y excepciones”, cláusula de política 7.3.2.

Para la elevación de privilegios diaria, la política para pymes también exige:

“Los privilegios elevados o administrativos requieren aprobación adicional del Director General o del Responsable de TI y deben estar documentados, limitados en el tiempo y sujetos a revisión periódica.”

De la sección “Requisitos de implantación de la política”, cláusula de política 6.2.2.

Para organizaciones de mayor tamaño, el conjunto de políticas empresariales profundiza más. La Política de gestión de cuentas de usuario y privilegios Política de gestión de cuentas de usuario y privilegios exige que:

“Las sesiones privilegiadas deben registrarse íntegramente, incluidos los comandos emitidos y las acciones realizadas. Los registros deben ser revisados periódicamente por revisores designados.”

De la sección “Requisitos de implantación de la política”, cláusula de política 6.4.2.

La misma política exige que las cuentas de acceso privilegiado temporal o de emergencia sigan un procedimiento break-glass documentado en la cláusula 6.2.5, mientras que la cláusula 7.4 describe los requisitos de dicho procedimiento.

La Política de control de acceso Política de control de acceso refuerza la conservación con fines de auditoría:

“Las decisiones de aprobación deben registrarse y conservarse con fines de auditoría durante un mínimo de 2 años.”

De la sección “Requisitos de gobernanza”, cláusula de política 5.3.2.

La Política de registro y supervisión para pymes Política de registro y supervisión - pyme identifica las expectativas de registro de autenticación:

“Registros de autenticación: intentos de inicio de sesión correctos y fallidos, duración de la sesión, uso de MFA”

De la sección “Requisitos de gobernanza”, cláusula de política 5.4.2.

En conjunto, estas cláusulas convierten el acceso de emergencia de una solución heroica improvisada en un evento controlado. La cuenta es excepcional, pero la gobernanza no lo es.

El enfoque de Zenith Blueprint para implantar PAM

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint trata el acceso privilegiado como un problema práctico de implantación, no como una declaración teórica de control. En la fase Controls in Action, paso 19, Technological Controls I, establece:

“En cualquier sistema de información, el acceso privilegiado es poder , y con ese poder viene el riesgo.”

De la fase Controls in Action, paso 19: Technological Controls I.

El paso 19 exige que las organizaciones identifiquen cuentas privilegiadas en entornos locales, nube, SaaS, desarrollo e infraestructura. Incluye administradores de dominio, usuarios root, administradores del inquilino de nube, superusuarios de bases de datos y controladores de canalizaciones de CI/CD. También enfatiza la minimización del acceso privilegiado mediante control de acceso basado en roles, elevación justo a tiempo y flujos de aprobación.

Esto importa porque muchos incidentes graves no empiezan con la cuenta break-glass formal. Empiezan con privilegios permanentes. Un ingeniero de nube conserva derechos de propietario “por si acaso”. Un administrador de bases de datos mantiene acceso al entorno de producción después de cambiar de equipo. Una cuenta de servicio de CI/CD tiene permisos amplios en varios entornos. Una cuenta de proveedor de servicios gestionados está exenta de MFA porque “necesitan acceso rápido”.

El paso 20 de Zenith Blueprint extiende el mismo razonamiento a los utilitarios privilegiados. Indica a las organizaciones que creen o actualicen un inventario de utilitarios privilegiados, restrinjan su ejecución a administradores autorizados, verifiquen que su uso se registra y genera alertas, y consideren el registro de scripts, como el registro de PowerShell mediante directivas de grupo. Esto es crítico porque una cuenta privilegiada a menudo es solo el punto de entrada. El daño ocurre cuando el atacante ejecuta herramientas que deshabilitan controles, extraen credenciales o se mueven lateralmente.

El paso 22 formaliza el ciclo de vida del control de acceso. Requiere aprovisionamiento y desaprovisionamiento estructurados, idealmente integrados con recursos humanos y respaldados por flujos de trabajo de solicitudes de acceso, con revisiones de acceso documentadas trimestralmente. El paso 16 vincula el ciclo de vida con la baja al exigir una lista de verificación de terminación de empleado que Recursos Humanos y TI utilicen conjuntamente, incluida la deshabilitación de cuentas, devolución de activos y recordatorios de acuerdo de confidencialidad.

Zenith Blueprint convierte PAM en un modelo operativo conectado: identidad, recursos humanos, utilitarios privilegiados, registro de eventos, respuesta a incidentes, revisiones de acceso y evidencias de auditoría se refuerzan mutuamente.

Un modelo práctico de gobernanza break-glass para 2026

Un proceso break-glass bien diseñado debe funcionar durante un fallo. Si depende del mismo proveedor de identidad, plataforma de tickets y servicio de chat que no están disponibles durante la caída, es puro teatro.

Al mismo tiempo, el acceso de emergencia no puede convertirse en un canal de elusión por comodidad. Clarysec suele diseñar la gobernanza break-glass en torno a cuatro capas: prevención, activación, observación y recuperación.

Para entornos en la nube, incluya administradores a nivel de inquilino, cuentas root de nube, administradores de emergencia del proveedor de identidad, cuentas de servicio privilegiadas, usuarios maestros de bases de datos, roles cluster-admin de Kubernetes, claves de despliegue de CI/CD, administradores de bóvedas de secretos y cuentas de soporte de terceros.

Para entornos híbridos, incluya administradores de dominio, administradores de copias de seguridad, administradores de hipervisores, administradores de cortafuegos, administradores de consola EDR y usuarios de utilitarios privilegiados.

Para entornos sensibles a la privacidad, incluya administradores que puedan acceder a bases de datos que contengan datos personales, registros que contengan identificadores, registros de recursos humanos, datos biométricos de verificación de identidad, sistemas de monitorización del fraude o herramientas de soporte al cliente.

El estado objetivo es sencillo de describir y difícil de simular: cada ruta de emergencia es conocida, aprobada, protegida, observable, reversible y revisada.

Un simulacro de evidencias break-glass de 60 minutos

Un CISO o responsable de cumplimiento puede ejecutar esta semana un ejercicio break-glass útil sin comprar una herramienta nueva. El objetivo no es solo confirmar que la cuenta funciona. El objetivo es demostrar que el control produce evidencias.

Escenario

Suponga que el proveedor de identidad principal está degradado. La elevación justo a tiempo normal no está disponible. Un clúster de bases de datos de producción necesita cambios de configuración de emergencia para restablecer el servicio. Debe activarse la cuenta de administrador de nube break-glass.

Paso 1: Confirmar que la cuenta está en el inventario privilegiado

Utilice Zenith Blueprint, fase Controls in Action, paso 19, para validar que la cuenta aparece en el inventario de cuentas privilegiadas. Registre el nombre de la cuenta y el entorno, propietario de negocio, propietario técnico, sistemas alcanzables, impacto en datos personales, método de autenticación, ubicación de la bóveda, método de rotación y fecha de la última prueba.

Si la cuenta falta, trátelo como una deficiencia de control y añádalo al Registro de Riesgos.

Paso 2: Verificar la alineación con la política

Mapee el evento con los requisitos de la Política de gestión de cuentas de usuario y privilegios para procedimientos break-glass documentados y registro de sesiones privilegiadas. Si es una pyme, use las cláusulas 7.3.1 y 7.3.2 de la Política de gestión de cuentas de usuario y privilegios para pymes como base mínima: documentada, protegida, necesaria, registrada, revisada y restablecida.

Mapee la conservación de aprobaciones con la cláusula 5.3.2 de la Política de control de acceso, que exige que las decisiones de aprobación se registren y conserven durante al menos 2 años.

Paso 3: Abrir un registro de acceso de emergencia

Cree un ticket o registro de incidente antes de la activación o en el momento de la activación. Incluya:

• Motivo de la emergencia
• Servicio afectado
• Cuenta solicitada
• Solicitante
• Aprobador
• Hora de inicio
• Hora prevista de finalización
• Impacto en clientes o regulatorio
• Impacto en datos personales del RGPD de la UE
• Marcador de vigilancia de notificación NIS2 o DORA

No espere hasta el final para reconstruir la historia. El valor de auditoría es mayor cuando el registro comienza antes de utilizar el acceso.

Paso 4: Activar y observar

Active la cuenta break-glass. Confirme que se utiliza MFA o autenticación compensatoria, que la sesión se graba, que se registran comandos o acciones administrativas, que los registros se envían al registro centralizado, que la sincronización horaria permite reconstruir la cronología y que se genera una alerta por el uso de la cuenta de emergencia.

Esto se alinea con Zenith Controls para 8.15 Registro de eventos, que describe el registro de eventos como la capa de datos fundamental para la supervisión y señala que los usuarios privilegiados y la ejecución de utilitarios privilegiados deben registrarse de forma completa.

Paso 5: Cerrar, restablecer y revisar

Después de la tarea de emergencia, deshabilite la cuenta o devuélvala a estado sellado, rote las credenciales o restablezca el factor de autenticación, revise los registros de sesión, documente comandos y cambios de configuración, confirme que no se produjo acceso innecesario a datos, actualice el registro del incidente, registre lecciones aprendidas y decida si se activan umbrales de notificación de NIS2, DORA o RGPD de la UE.

Si se accedió a datos personales, involucre al DPO. Si el evento causó interrupción del servicio o pudo causar impacto material, involucre al responsable de notificación NIS2 o DORA. Si la cuenta break-glass falló, documéntelo como un hallazgo de resiliencia operativa, no meramente como un problema de IAM.

Mapeo de cumplimiento cruzado para controles PAM y break-glass

El modelo de gobernanza más sólido no duplica controles para cada regulación. Construye una única cadena de evidencias que respalda múltiples obligaciones.

NIST CSF 2.0 es especialmente útil al traducir PAM en un Perfil Actual y un Perfil Objetivo. Su método de perfiles empieza por el alcance, después recopila políticas, prioridades de riesgo, registros, requisitos, prácticas y roles de trabajo, antes de crear un plan de acción priorizado. Para el acceso privilegiado, esto significa delimitar el perfil alrededor de la seguridad de identidad, la administración de nube, la resiliencia frente a ransomware, los sistemas financieros críticos o el acceso de proveedores.

Para entidades financieras cubiertas por DORA, DORA funciona como el régimen sectorial específico de la UE de ciberresiliencia para obligaciones equivalentes de riesgo e incidentes de NIS2. Eso no hace que NIS2 sea irrelevante. Significa que la entidad financiera debe utilizar DORA como régimen rector para los requisitos de riesgo e incidentes de TIC, manteniendo la coordinación con estrategias nacionales de ciberseguridad, autoridades competentes y CSIRT cuando proceda.

Cómo prueban los auditores las evidencias de acceso privilegiado

Los auditores no evalúan PAM solo leyendo políticas. Triangulan política, configuración, registros, tickets, entrevistas y práctica observada.

La metodología de auditoría de Zenith Controls para derechos de acceso privilegiado referencia las prácticas de auditoría de ISO/IEC 19011:2018. Los auditores revisan políticas que definen derechos elevados, aprovisionamiento, supervisión y procedimientos de revocación. Examinan inventarios de cuentas de usuario, registros de asignación de privilegios y registros de eventos. Corroboran evidencias mediante entrevistas, herramientas PAM, servicios de directorio y muestras de registros.

Para los derechos de acceso, Zenith Controls señala que los auditores muestrean solicitudes de acceso de usuarios, verifican aprobaciones documentadas y confirman que TI concedió solo el acceso aprobado. También comparan los roles de usuario con los derechos reales, verificando si se aplica el mínimo privilegio. Para el registro de eventos, los auditores inspeccionan el alcance del registro, tipos de eventos, períodos de conservación, protecciones y entradas reales de registros. Evalúan si se capturan y revisan los inicios de sesión fallidos, el acceso a datos sensibles y los cambios de configuración.

Un buen paquete de evidencias break-glass incluye:

• Solicitud de acceso de emergencia aprobada
• Contexto de incidente o indisponibilidad
• Identidad del usuario que activa el acceso
• Identidad del aprobador
• Hora de inicio y finalización
• Evidencia de MFA o autenticación
• Grabación de sesión o registro de comandos
• Registros del sistema y alerta SIEM
• Cambios realizados
• Confirmación de restablecimiento de credenciales
• Revisión posterior al uso
• Evaluación de acceso a datos
• Evaluación de notificación regulatoria
• Acciones correctivas si algo falló

Si su simulacro no puede producir este paquete, el control no está preparado para auditoría.

El fallo oculto: acceso privilegiado de terceros

Muchas organizaciones gobiernan mejor a los administradores empleados que a los administradores de proveedores. En entornos de nube, SaaS, fintech y servicios gestionados, eso está al revés.

El artículo 21 de NIS2 incluye seguridad de la cadena de suministro y relaciones con proveedores directos y proveedores de servicios. Los artículos 28 a 30 de DORA van más allá para las entidades financieras, al exigir estrategia de riesgo de terceros de TIC, registros de contratos de servicios de TIC, diligencia debida, evaluación del riesgo de concentración, derechos de auditoría, derechos de terminación, estrategias de salida y medidas contractuales de seguridad.

El acceso privilegiado de proveedores debe estar dentro del alcance de PAM si el proveedor puede administrar producción, dar soporte a funciones críticas o importantes, acceder a datos personales, modificar configuraciones de seguridad, gestionar copias de seguridad, desplegar código u operar herramientas de supervisión.

Clarysec normalmente espera que los controles de acceso privilegiado de proveedores incluyan:

• Usuarios nominativos del proveedor, no cuentas compartidas del proveedor
• Requisitos contractuales de seguridad para el acceso privilegiado
• MFA y acceso remoto seguro
• Ventanas de acceso limitadas en el tiempo
• Aprobación del cliente para el acceso de emergencia
• Registro de sesiones o pistas de auditoría equivalentes
• Revocación inmediata cuando cambie el personal
• Obligaciones de cooperación en incidentes
• Conservación de evidencias alineada con las necesidades de auditoría del cliente
• Plan de salida para eliminar el acceso del proveedor

Los resultados de cadena de suministro de NIST CSF 2.0 se alinean claramente aquí. Exigen roles y responsabilidades de proveedores, priorización de proveedores por criticidad, requisitos en contratos, diligencia debida, supervisión continua, participación del proveedor en la planificación de incidentes y planes de riesgo posteriores al contrato.

Si una cuenta de proveedor de servicios gestionados está exenta de su flujo de trabajo interno de PAM, eso no es una comodidad. Es una excepción de alto riesgo que debe estar en el Registro de Riesgos, el registro de proveedores y la revisión de accesos.

Hallazgos comunes sobre PAM y break-glass en 2026

En los trabajos de Clarysec, los hallazgos rara vez sorprenden. Suelen ser combinaciones de buenas intenciones, presión operativa y evidencias incompletas.

Los hallazgos más comunes son:

• Existen cuentas break-glass, pero no figuran en el inventario de cuentas privilegiadas.
• Las cuentas de emergencia están excluidas de las revisiones de acceso normales.
• La organización no puede demostrar quién utilizó una cuenta de emergencia.
• La cuenta no se restableció después de su uso.
• Las sesiones privilegiadas se registran, pero los comandos no.
• Los registros existen localmente, pero no están protegidos frente a usuarios privilegiados.
• Las cuentas root de nube no se prueban.
• Los procesos de recuperación de MFA no están documentados.
• Se ignora el acceso privilegiado para canalizaciones de CI/CD y cuentas de servicio.
• El acceso de soporte de terceros elude la aprobación interna.
• La aprobación de acceso existe en mensajes de chat, pero no se conserva como evidencia de auditoría.
• La baja elimina correo electrónico y VPN, pero no derechos de administrador SaaS.
• El DPO no participa cuando el acceso privilegiado puede exponer datos personales.
• Los playbooks de incidentes no incluyen puntos de decisión de notificación NIS2, DORA o RGPD de la UE.

Cada hallazgo puede tratarse mediante el tratamiento de riesgos de ISO/IEC 27001:2022. Identifique el riesgo, asigne un propietario, seleccione controles, actualice la Declaración de Aplicabilidad, implante el Plan de Tratamiento de Riesgos y conserve evidencias documentadas. Esa es la fuerza de utilizar un SGSI en lugar de un conjunto disperso de tareas de seguridad.

Cómo se ve un buen modelo

Un modelo operativo maduro de PAM y break-glass tiene cinco rutinas recurrentes.

Primero, inventariar el acceso privilegiado mensual o continuamente. Incluya administradores humanos, cuentas de servicio, cuentas de emergencia, roles de nube, identidades de CI/CD, usuarios de bases de datos, utilitarios privilegiados y administradores de terceros.

Segundo, aplicar el mínimo privilegio mediante roles, elevación justo a tiempo y aprobaciones. Los privilegios permanentes deben ser raros, justificados y revisarse con mayor frecuencia que el acceso estándar de usuarios.

Tercero, supervisar el comportamiento privilegiado. Registre autenticación, duración de sesión, uso de MFA, comandos, cambios de configuración, exportaciones de datos, intentos fallidos, elevación de privilegios y ejecución de utilitarios privilegiados.

Cuarto, probar las cuentas break-glass antes de la emergencia. Una cuenta break-glass que nunca se ha probado es una suposición, no un control.

Quinto, informar a la dirección. Tanto NIS2 como DORA elevan la ciberseguridad y el riesgo de las TIC a responsabilidad del órgano de dirección. El consejo de administración no necesita cada registro de comandos, pero sí necesita métricas: número de cuentas privilegiadas, revisiones vencidas, activaciones de emergencia, cuentas de administradores de proveedores, pruebas fallidas, excepciones críticas y estado de remediación.

Aquí es donde el conjunto de herramientas de Clarysec se vuelve práctico. La biblioteca de políticas proporciona el lenguaje de gobernanza. Zenith Blueprint proporciona la secuencia de implantación. Zenith Controls proporciona el mapeo de cumplimiento cruzado, relaciones de control, normas de apoyo y metodología de auditoría.

Próximos pasos: convertir el acceso de emergencia en resiliencia preparada para auditoría

Si su organización no ha probado el acceso break-glass en los últimos 90 días, empiece ahí. No comience con un taller de selección de herramientas. Empiece con evidencias.

1. Construya o actualice su inventario de cuentas privilegiadas.
2. Identifique cada cuenta break-glass y ruta de administración de emergencia.
3. Mapee cada cuenta con el propietario de negocio, propietario del sistema e impacto en datos.
4. Confirme la cobertura de políticas utilizando la Política de gestión de cuentas de usuario y privilegios Política de gestión de cuentas de usuario y privilegios de Clarysec o la Política de gestión de cuentas de usuario y privilegios para pymes Política de gestión de cuentas de usuario y privilegios - pyme.
5. Utilice Zenith Blueprint Zenith Blueprint, fase Controls in Action, pasos 19, 20, 22 y 16, para conectar acceso privilegiado, utilitarios privilegiados, revisiones del ciclo de vida y baja.
6. Utilice Zenith Controls Zenith Controls para mapear los controles ISO/IEC 27002:2022 8.2, 5.18 y 8.15 con las expectativas de evidencias de NIS2, DORA, RGPD de la UE y NIST.
7. Ejecute un simulacro de evidencias break-glass y registre los resultados.
8. Añada las deficiencias al Plan de Tratamiento de Riesgos y haga seguimiento de la remediación hasta el cierre.

El acceso privilegiado es poder. El acceso break-glass es poder de emergencia. En 2026, las organizaciones que se recuperen limpiamente de ransomware, indisponibilidades de nube y fallos de identidad serán las que puedan demostrar que el acceso de emergencia estuvo controlado antes, durante y después de la crisis.

Clarysec puede ayudarle a construir esa prueba, desde la política hasta el mapeo de controles y las evidencias preparadas para auditoría. Empiece con Zenith Blueprint, combínelo con la Política de gestión de cuentas de usuario y privilegios y la Política de control de acceso, y después utilice Zenith Controls para mostrar cómo su programa PAM respalda ISO/IEC 27001:2022, NIS2, DORA, RGPD de la UE, NIST CSF 2.0 y COBIT 2019.