How does DORA affect emergency access to ICT systems?
Glassbreak Team · Published 2026-07-17
DORA affects emergency access to ICT systems mainly through two of its requirements: Article 11, which requires financial entities to have response and recovery procedures — including business continuity and communication plans — as part of managing ICT risk, and Article 9, which requires protection and prevention measures that preserve confidentiality, integrity, and availability even while responding to an incident. Together, these are commonly read as requiring some controlled way to reach critical systems during a disruption, since a recovery plan that can't actually get access to what it needs to recover falls short of the requirement. DORA doesn't name a specific mechanism like break-glass access by title, but a documented, evidenced emergency-access path is a practical way many financial entities and their suppliers satisfy the underlying expectation.
Who DORA actually applies to
DORA (Regulation (EU) 2022/2554) has applied since 17 January 2025 and sets uniform ICT risk-management requirements on EU financial entities — banks, insurers, investment firms, and a wide range of other regulated entities. It also extends a contractual regime, under Article 28-30, to the ICT third-party service providers (ICT TPPs) those entities rely on. A narrower category, Critical ICT Third-Party Providers (CTPPs), designated under Article 31 based on systemic-impact criteria, faces direct DORA oversight. Most vendors, including most incident-communications and emergency-access tools, fall into the broader ICT TPP category rather than the CTPP one — subject to the financial entity's contract terms, not to DORA's supervisory regime directly.
Where emergency access fits in the five pillars
DORA organizes its requirements into five areas. Two are directly relevant to how a financial entity's staff reach systems during an incident:
ICT risk management (Articles 5-16). Article 11's response-and-recovery requirement is the closest direct hook: financial entities need documented procedures for restoring systems and communicating during a disruption, which in practice requires some way to authorize and log emergency access to the systems being recovered.
ICT third-party risk (Articles 28-30). This is where a supplier's own emergency-access posture becomes the financial entity's problem, contractually. Article 30 sets out mandatory contract terms — service descriptions, processing locations, notification timing, audit rights, exit plans — that a financial entity must have in its agreement with any ICT third-party provider handling a critical or important function.
What this means for choosing a supplier
A financial entity evaluating an emergency-access or crisis-communications vendor for DORA readiness is mainly checking two things: does the vendor's own access-control design hold up (quorum approval rather than a single admin override, time-boxed access, a full audit trail), and does the vendor's contract cover the Article 30 terms the financial entity needs for its own Register of Information and supplier risk assessment. Neither of these requires the vendor to be a financial entity or a CTPP itself — they're supplier due-diligence questions, not direct-regulation questions.
How Glassbreak fits this picture
Glassbreak is not a financial entity and is not directly subject to DORA. It can be an ICT third-party service provider to financial-entity customers, and its Article 28-30 posture — including the conclusion that it does not meet the Article 31 CTPP designation criteria — is published in full at /trust/dora. The underlying access-control design that supports Article 11-style response-and-recovery needs is the same quorum-based approval model described on the security page: recovering a team secret or triggering emergency access requires a threshold of independently authorized people, not a single override, and every step is logged. For financial-services and other regulated customers weighing EU data residency alongside these controls, data residency for DORA & NIS2 covers that dimension specifically, and the underlying vocabulary of quorum-based recovery is explained in what is quorum-based (Shamir) secret sharing.
This page is general information about how DORA's requirements typically interact with emergency-access design; it isn't legal advice, and a financial entity's specific compliance obligations should be confirmed with its own counsel and read directly against the regulation.
Frequently asked questions
- Does DORA specifically require a break-glass procedure?
- DORA doesn't name "break-glass" as a specific required mechanism. Article 11 requires response and recovery procedures, and Article 9 requires protection and prevention measures covering confidentiality, integrity, and availability — together these are commonly read as requiring some form of controlled emergency access, since a recovery plan that can't actually reach the systems it needs to recover isn't operationally complete. The specific implementation (break-glass accounts, quorum-approved secret recovery, or another mechanism) is a design choice within that requirement, not a named DORA control.
- Is a vendor like Glassbreak directly regulated by DORA?
- Only financial entities and Critical ICT Third-Party Providers (CTPPs) are directly subject to DORA's full regime. A vendor that isn't itself a financial entity and doesn't meet the Article 31 CTPP designation criteria is an ICT third-party service provider to any financial-entity customers, subject to the contractual terms those customers must include under Article 28-30, rather than to DORA's supervisory regime directly.
- What should a financial entity ask an emergency-access vendor about DORA readiness?
- Focus on what Article 30's contract terms actually require: a clear description of the service, processing locations, service-level commitments, incident-notification timing aligned to the entity's own reporting cascade, audit and access rights, and an exit plan. For emergency-access specifically, also ask how access is authorized and logged, and whether recovery of any secret depends on a single party (including the vendor) being available and trustworthy.
- Does DORA require specific incident-notification timing from suppliers?
- DORA sets the financial entity's own reporting cascade to competent authorities on tight timelines. Suppliers aren't directly bound by those same deadlines, but a financial entity's contracts with ICT third-party providers typically need notification terms that give the entity enough lead time to meet its own obligations — this is a contractual alignment, not the supplier being directly regulated under the same clock.