PAM and Break-Glass Accounts for ISO 27001 in 2026

At 02:14 on a Sunday morning, the incident commander gets the message every CISO dreads: “Production authentication is failing. Admin console is unreachable. Database failover is stuck.”

The cloud engineer on call can see the issue, but cannot fix it. Their normal privileged role depends on the same identity provider that is now degraded. The operations lead asks for the emergency administrator credential. The compliance manager asks whether the break-glass account has ever been tested. The DPO asks whether accessing the production database may expose personal data. The CISO asks the question that determines whether this becomes a controlled recovery or an audit nightmare:

“Can we prove who used emergency access, why, what they did, and that the account was reset afterwards?”

A different organization may face the same problem in a quieter room. A FinTech CISO sits across from external auditors after a cloud database misconfiguration. The incident was fixed quickly, but the root cause was not comforting. A third-party developer had standing administrative privileges. When the primary admin was unavailable, the developer used a break-glass account based on a shared password stored in a “secure” note available to the DevOps team.

The auditors were not focused only on the misconfiguration. They asked whether access was time-bound, whether individual accountability existed, whether commands were logged, whether personal data was protected under GDPR Article 32, whether DORA ICT risk obligations were met, and whether NIS2 cyber hygiene expectations were demonstrable.

That is the real-world pressure point of privileged access management and break-glass accounts in 2026. PAM is no longer a niche identity-security project. It is where ransomware, cloud compromise, supplier risk, data protection, operational resilience and audit evidence converge.

Privileged access is where attackers try to win. Break-glass access is where defenders try to recover. Both rely on the same dangerous capability: elevated access that can bypass controls, change configurations, read sensitive data, rotate keys, disable logging, restore backups, deploy code, or destroy evidence.

Clarysec’s practical position is simple: emergency access is necessary, but unmanaged emergency access is unmanaged risk. The right answer is not “no break-glass accounts.” The right answer is a governed privileged access management model with inventory, approval, time limits, strong authentication, session logging, post-use review, credential reset and audit evidence.

Why privileged access is a board-level compliance issue

In lower-maturity environments, privileged access is often treated as an IT administration task. Someone needs admin rights, a ticket is opened, a role is granted, and the business moves on. That model does not survive modern ransomware, cloud-native infrastructure, NIS2 accountability, DORA operational resilience or GDPR breach scrutiny.

The NIS2 Directive places cybersecurity governance in the boardroom. Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee implementation and follow cybersecurity training. Article 21 requires appropriate and proportionate technical, operational and organizational measures, including risk analysis, incident handling, business continuity, supply chain security, control effectiveness, cyber hygiene, HR security, access control, asset management and MFA or continuous authentication where appropriate.

For SaaS providers, managed service providers, managed security providers, cloud services, data centres and other digital infrastructure organizations, NIS2 applicability depends on sector, size, role, cross-border impact and EU establishment. The operational lesson is direct: access control is no longer buried in a technical annex. It is part of the cyber hygiene baseline that management must approve, monitor and correct.

For financial entities, the Digital Operational Resilience Act changes the language but not the underlying risk. DORA applies from 17 January 2025 and establishes a uniform framework for ICT risk management, major ICT-related incident reporting, digital operational resilience testing and ICT third-party risk management. Article 5 requires governance and control arrangements for ICT risk, with the management body defining, approving, overseeing and being responsible for ICT risk arrangements. Article 6 requires a documented ICT risk management framework with policies, procedures, protocols and tools to protect ICT assets. Article 17 requires an ICT-related incident management process that detects, records, classifies, escalates and restores secure operations.

GDPR adds the privacy and accountability lens. Article 5(1)(f) requires personal data to be processed with integrity and confidentiality. Article 5(2) requires accountability. Article 25 requires data protection by design and by default. Article 32 requires appropriate technical and organizational measures for security of processing. If a privileged user can export customer records, access special category data, disable audit logs or change retention settings without review, the organization has not merely made an IAM mistake. It may be unable to demonstrate appropriate security.

ISO/IEC 27001:2022 is the management-system backbone that allows these obligations to be handled through one integrated program. Clause 4.2 requires the organization to understand interested parties and their requirements, including legal, regulatory and contractual obligations. Clause 5.1 requires leadership and commitment. Clause 6.1.2 requires information security risk assessment. Clause 6.1.3 requires risk treatment. Clause 8 requires operational planning and control.

For privileged access, this shifts the conversation from “which PAM tool should we buy?” to “which risks are we treating, which controls are selected, who owns them, how are they operated, and what evidence proves they work?”

PAM is not one control, it is a chain of evidence

A PAM tool can vault passwords, broker sessions, record keystrokes, rotate credentials and enforce just-in-time access. Those capabilities matter. But if the organization has not defined privileged roles, approved emergency access, mapped access to assets, reviewed rights, protected logs and trained administrators, the tool becomes a partial control with weak audit defensibility.

The most useful way to govern privileged access is to think in control outcomes, not tool names.

The Zenith Controls: The Cross-Compliance Guide Zenith Controls treats ISO/IEC 27002:2022 control 8.2, Privileged access rights, as the center of gravity for PAM. It classifies this control as preventive, supporting confidentiality, integrity and availability, aligned to the cybersecurity concept Protect, the operational capability Identity and access management, and the security domain Protection.

Control 8.2 is powerful because it connects to the surrounding controls that make privileged access auditable:

This is why an auditor rarely stops at the question, “Do you have a PAM system?” The stronger audit questions are: Do you have a privileged account inventory? Are privileged roles approved? Are rights time-bound? Are emergency credentials secured? Can you prove who used them? Are commands logged? Are supplier administrators included? Are access rights reviewed? Were credentials reset? Were exceptions risk accepted?

The Zenith Controls access-rights mapping makes the point directly: access rights management operationalizes access control principles such as least privilege, need-to-know and authorization, while privileged accounts require special scrutiny and prompt revocation when no longer necessary.

Policy requirements for trustworthy break-glass access

A break-glass account is not a shared admin password in a sealed envelope. In 2026, that model is too weak for cloud, fintech, SaaS, healthcare, managed services and regulated digital operations.

A defensible break-glass model needs seven minimum policy rules:

1. The account must be documented.
2. The account must be approved.
3. Use must be uniquely attributable where technically possible.
4. Use must be limited to genuine emergencies.
5. Use must be logged and reviewed.
6. Credentials or authentication factors must be reset or rotated after use.
7. The account must be tested and included in audit scope.

Clarysec’s policy library turns these principles into usable governance language.

The User Account and Privilege Management Policy-sme User Account and Privilege Management Policy - SME states:

“Emergency access (e.g., “break glass” administrator accounts) must be clearly documented, secured, and used only when absolutely necessary.”

From section “Risk Treatment and Exceptions,” policy clause 7.3.1.

The same SME policy continues:

“Such accounts must be logged, reviewed after use, and reset after each emergency event.”

From section “Risk Treatment and Exceptions,” policy clause 7.3.2.

For day-to-day privilege elevation, the SME policy also requires:

“Elevated or administrative privileges require additional approval by the General Manager or IT Lead and must be documented, time-bound, and subject to periodic review.”

From section “Policy Implementation Requirements,” policy clause 6.2.2.

For larger organizations, the enterprise policy set goes deeper. The User Account and Privilege Management Policy User Account and Privilege Management Policy requires that:

“Privileged sessions must be fully logged, including commands issued and actions performed. Logs must be reviewed periodically by designated reviewers.”

From section “Policy Implementation Requirements,” policy clause 6.4.2.

The same policy requires temporary or emergency privileged access accounts to follow a documented break-glass procedure in clause 6.2.5, while clause 7.4 outlines the requirements for that procedure.

The Access Control Policy Access Control Policy reinforces audit retention:

“Approval decisions must be logged and retained for audit purposes for a minimum of 2 years.”

From section “Governance Requirements,” policy clause 5.3.2.

The Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME identifies authentication logging expectations:

“Authentication logs: Successful and failed login attempts, session duration, MFA usage”

From section “Governance Requirements,” policy clause 5.4.2.

Together, these clauses turn emergency access from a heroic workaround into a controlled event. The account is exceptional, but the governance is not.

The Zenith Blueprint approach to implementing PAM

The Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint treats privileged access as a practical implementation problem, not a theoretical control statement. In the Controls in Action phase, Step 19, Technological Controls I, it states:

“In any information system, privileged access is power , and with that power comes risk.”

From the Controls in Action phase, Step 19: Technological Controls I.

Step 19 requires organizations to identify privileged accounts across on-premises, cloud, SaaS, development and infrastructure environments. It includes domain administrators, root users, cloud tenant administrators, database superusers and CI/CD pipeline controllers. It also emphasizes minimizing privileged access through role-based access control, just-in-time elevation and approval workflows.

That matters because many serious incidents do not begin with the formal break-glass account. They begin with standing privilege. A cloud engineer keeps owner rights “just in case.” A database administrator retains production access after moving teams. A CI/CD service account has broad permissions across environments. A managed service provider account is exempt from MFA because “they need quick access.”

Step 20 of the Zenith Blueprint extends the same reasoning to privileged utilities. It instructs organizations to create or update a privileged utility inventory, restrict execution to authorized administrators, verify that use is logged and alert-enabled, and consider script logging, such as PowerShell logging through group policy. This is critical because a privileged account is often only the entry point. The damage occurs when the attacker runs tools that disable controls, dump credentials or move laterally.

Step 22 formalizes the access control lifecycle. It calls for structured provisioning and deprovisioning, ideally integrated with HR and supported by access request workflows, with quarterly documented access reviews. Step 16 ties the lifecycle to offboarding by requiring an employee termination checklist that HR and IT jointly use, including account disablement, asset return and NDA reminders.

The Zenith Blueprint makes PAM a connected operating model: identity, HR, privileged utilities, logging, incident response, access reviews and audit evidence reinforce each other.

A practical break-glass governance model for 2026

A well-designed break-glass process must work during failure. If it depends on the same identity provider, ticketing platform and chat service that are unavailable during the outage, it is theater.

At the same time, emergency access cannot become a bypass channel for convenience. Clarysec typically designs break-glass governance around four layers: prevention, activation, observation and recovery.

For cloud environments, include tenant-level administrators, cloud root accounts, emergency identity provider administrators, privileged service accounts, database master users, Kubernetes cluster-admin roles, CI/CD deploy keys, secrets vault administrators and third-party support accounts.

For hybrid environments, include domain administrators, backup administrators, hypervisor administrators, firewall administrators, EDR console administrators and privileged utility users.

For privacy-sensitive environments, include administrators who can access databases containing personal data, logs containing identifiers, HR records, biometric identity verification data, fraud monitoring systems or customer support tools.

The target state is simple to describe and difficult to fake: every emergency path is known, approved, secured, observable, reversible and reviewed.

A 60-minute break-glass evidence drill

A CISO or compliance manager can run a useful break-glass exercise this week without buying a new tool. The objective is not only to confirm that the account works. The objective is to prove that the control produces evidence.

Scenario

Assume the primary identity provider is degraded. Normal just-in-time elevation is unavailable. A production database cluster needs emergency configuration changes to restore service. The break-glass cloud administrator account must be activated.

Step 1: Confirm the account is in the privileged inventory

Use the Zenith Blueprint, Controls in Action phase, Step 19, to validate that the account appears in the privileged account inventory. Record the account name and environment, business owner, technical owner, reachable systems, personal data impact, authentication method, vault location, rotation method and last test date.

If the account is missing, treat that as a control gap and add it to the risk register.

Step 2: Check policy alignment

Map the event to the User Account and Privilege Management Policy requirements for documented break-glass procedures and privileged session logging. If you are an SME, use User Account and Privilege Management Policy-sme clauses 7.3.1 and 7.3.2 as the minimum baseline: documented, secured, necessary, logged, reviewed and reset.

Map approval retention to Access Control Policy clause 5.3.2, which requires approval decisions to be logged and retained for at least 2 years.

Step 3: Open an emergency access record

Create a ticket or incident record before or at activation. Include:

• Emergency reason
• Impacted service
• Requested account
• Requester
• Approver
• Start time
• Expected end time
• Customer or regulatory impact
• GDPR personal data impact
• NIS2 or DORA reporting watch flag

Do not wait until the end to reconstruct the story. The audit value is strongest when the record begins before access is used.

Step 4: Activate and observe

Activate the break-glass account. Confirm that MFA or compensating authentication is used, the session is recorded, commands or administrative actions are logged, logs are forwarded to centralized logging, time synchronization supports timeline reconstruction, and an alert is generated for emergency account use.

This aligns with Zenith Controls for 8.15 Logging, which describes logging as the foundational data layer for monitoring and notes that privileged users and privileged utility execution must be logged comprehensively.

Step 5: Close, reset and review

After the emergency task, disable or return the account to sealed status, rotate credentials or reset the authentication factor, review session logs, document commands and configuration changes, confirm no unnecessary data access occurred, update the incident record, record lessons learned and decide whether NIS2, DORA or GDPR notification thresholds are triggered.

If personal data was accessed, involve the DPO. If the event caused service disruption or could cause material impact, involve the NIS2 or DORA reporting owner. If the break-glass account failed, document it as an operational resilience finding, not merely an IAM issue.

Cross-compliance mapping for PAM and break-glass controls

The strongest governance model does not duplicate controls for every regulation. It builds one evidence chain that supports multiple obligations.

NIST CSF 2.0 is especially useful when translating PAM into a Current Profile and Target Profile. Its profile method begins with scope, then gathers policies, risk priorities, registers, requirements, practices and work roles, before creating a prioritized action plan. For privileged access, that means scoping the profile around identity security, cloud administration, ransomware resilience, critical financial systems or supplier access.

For DORA-covered financial entities, DORA functions as the sector-specific EU cyber resilience regime for equivalent NIS2 risk and incident obligations. That does not make NIS2 irrelevant. It means the financial entity should use DORA as the governing regime for ICT risk and incident requirements while maintaining coordination with national cybersecurity strategies, competent authorities and CSIRTs where applicable.

How auditors test privileged access evidence

Auditors do not assess PAM only by reading policy. They triangulate policy, configuration, logs, tickets, interviews and observed practice.

The Zenith Controls audit methodology for privileged access rights references ISO/IEC 19011:2018 audit practices. Auditors review policies defining elevated rights, provisioning, monitoring and revocation procedures. They examine user account inventories, privilege assignment records and logs. They corroborate evidence through interviews, PAM tools, directory services and log samples.

For access rights, Zenith Controls notes that auditors sample user access requests, verify documented approvals and confirm IT granted only approved access. They also compare user roles against actual rights, checking whether least privilege is enforced. For logging, auditors inspect logging scope, event types, retention periods, protections and actual log entries. They assess whether failed logins, sensitive data access and configuration changes are captured and reviewed.

A good break-glass evidence package includes:

• Approved emergency access request
• Incident or outage context
• Identity of the user activating access
• Approver identity
• Start and end time
• MFA or authentication evidence
• Session recording or command log
• System logs and SIEM alert
• Changes made
• Confirmation of credential reset
• Post-use review
• Data access assessment
• Regulatory notification assessment
• Corrective actions if anything failed

If your drill cannot produce this package, the control is not audit-ready.

The hidden failure: third-party privileged access

Many organizations govern employee administrators better than supplier administrators. For cloud, SaaS, fintech and managed service environments, that is backwards.

NIS2 Article 21 includes supply chain security and relationships with direct suppliers and service providers. DORA Articles 28 to 30 go further for financial entities, requiring ICT third-party risk strategy, registers of ICT service contracts, due diligence, concentration risk assessment, audit rights, termination rights, exit strategies and contractual security measures.

Privileged supplier access should be in PAM scope if the supplier can administer production, support critical or important functions, access personal data, modify security configurations, manage backups, deploy code or operate monitoring tools.

Clarysec typically expects supplier privileged access controls to include:

• Named supplier users, not shared supplier accounts
• Contractual security requirements for privileged access
• MFA and secure remote access
• Time-bound access windows
• Customer approval for emergency access
• Session logging or equivalent audit trails
• Immediate revocation when personnel change
• Incident cooperation obligations
• Evidence retention aligned to customer audit needs
• Exit plan for removing supplier access

NIST CSF 2.0 supply chain outcomes align strongly here. They call for supplier roles and responsibilities, supplier prioritization by criticality, requirements in contracts, due diligence, ongoing monitoring, supplier involvement in incident planning and post-contract risk plans.

If a managed service provider account is exempt from your internal PAM workflow, that is not a convenience. It is a high-risk exception that belongs in the risk register, supplier register and access review.

Common PAM and break-glass findings in 2026

Across Clarysec engagements, the findings are rarely surprising. They are usually combinations of good intentions, operational pressure and incomplete evidence.

The most common findings are:

• Break-glass accounts exist but are not listed in the privileged account inventory.
• Emergency accounts are excluded from normal access reviews.
• The organization cannot prove who used an emergency account.
• The account was not reset after use.
• Privileged sessions are logged, but commands are not.
• Logs exist locally but are not protected from privileged users.
• Cloud root accounts are not tested.
• MFA recovery processes are undocumented.
• Privileged access for CI/CD pipelines and service accounts is ignored.
• Third-party support access bypasses internal approval.
• Access approval exists in chat messages but is not retained as audit evidence.
• Offboarding removes email and VPN but not SaaS administrator rights.
• The DPO is not involved when privileged access may expose personal data.
• Incident playbooks do not include NIS2, DORA or GDPR notification decision points.

Each finding can be handled through ISO/IEC 27001:2022 risk treatment. Identify the risk, assign an owner, select controls, update the Statement of Applicability, implement the treatment plan and retain documented evidence. That is the power of using an ISMS instead of a scattered set of security tasks.

What good looks like

A mature PAM and break-glass operating model has five repeating routines.

First, inventory privileged access monthly or continuously. Include human administrators, service accounts, emergency accounts, cloud roles, CI/CD identities, database users, privileged utilities and third-party administrators.

Second, enforce least privilege through roles, just-in-time elevation and approvals. Standing privileges should be rare, justified and reviewed more frequently than standard user access.

Third, monitor privileged behavior. Log authentication, session duration, MFA usage, commands, configuration changes, data exports, failed attempts, privilege escalation and privileged utility execution.

Fourth, test break-glass accounts before the emergency. A break-glass account that has never been tested is an assumption, not a control.

Fifth, report to management. NIS2 and DORA both raise cybersecurity and ICT risk to management-body responsibility. The board does not need every command log, but it does need metrics: privileged account count, overdue reviews, emergency activations, supplier admin accounts, failed tests, critical exceptions and remediation status.

This is where Clarysec’s toolkit becomes practical. The policy library gives the governance language. The Zenith Blueprint gives the implementation sequence. Zenith Controls gives the cross-compliance mapping, control relationships, supporting standards and audit methodology.

Next steps: turn emergency access into audit-ready resilience

If your organization has not tested break-glass access in the last 90 days, start there. Do not begin with a tool selection workshop. Begin with evidence.

1. Build or update your privileged account inventory.
2. Identify every break-glass account and emergency admin path.
3. Map each account to business owner, system owner and data impact.
4. Confirm policy coverage using Clarysec’s User Account and Privilege Management Policy User Account and Privilege Management Policy or User Account and Privilege Management Policy-sme User Account and Privilege Management Policy - SME.
5. Use the Zenith Blueprint Zenith Blueprint Controls in Action phase, Steps 19, 20, 22 and 16 to connect privileged access, privileged utilities, lifecycle reviews and offboarding.
6. Use Zenith Controls Zenith Controls to map ISO/IEC 27002:2022 controls 8.2, 5.18 and 8.15 to NIS2, DORA, GDPR and NIST evidence expectations.
7. Run a break-glass evidence drill and record the results.
8. Add gaps to the risk treatment plan and track remediation to closure.

Privileged access is power. Break-glass access is emergency power. In 2026, the organizations that recover cleanly from ransomware, cloud outages and identity failures will be the ones that can prove emergency access was controlled before, during and after the crisis.

Clarysec can help you build that proof, from policy to control mapping to audit-ready evidence. Start with the Zenith Blueprint, pair it with the User Account and Privilege Management Policy and Access Control Policy, then use Zenith Controls to show how your PAM program supports ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT 2019.