DORA — Digital Operational Resilience Act
Status: ICT third-party service provider to FS customers · not designated CTPP · last updated 27 May 2026
The EU Digital Operational Resilience Act (Regulation (EU) 2022/2554) entered into force on 16 January 2023 and has applied since 17 January 2025. It sets uniform requirements on financial entities for managing ICT risk, and extends a contractual + supervisory regime to the ICT third-party service providers (ICT TPPs) they rely on.
Glassbreak is not itself a financial entity and so is not directly subject to DORA. We can be an ICT third-party service provider to customers who are financial entities. This page describes what we offer those customers under DORA's Article 28–30 contractual regime, our position on the Critical ICT Third-Party Provider (CTPP) designation criteria, and our Article 6/7/8 operational evidence.
Are we a CTPP?
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| 31(2)(a) | Systemic impact on the financial system | N/A | No. Glassbreak serves emergency communications, not transaction processing, settlement, market data, or any of the workflows that have systemic potential. Failure of Glassbreak does not impair financial-system stability. |
| 31(2)(b) | Systemic importance of the financial entities relying on us | N/A | Our customer base today is not concentrated in systemically important institutions. Use case is incident communications; not embedded in any client's core operating processes. |
| 31(2)(c) | Reliance on the same provider for critical or important functions | N/A | For customers who do use Glassbreak, the function (emergency communications) is critical-or-important under their internal classification, but they retain alternative comms channels (Slack, PagerDuty, telephony) so we are not the sole-provider of that function for any one customer. |
| 31(2)(d) | Substitutability — alternatives at acceptable cost / quality | N/A | Substitutable. Multiple incident-comms platforms exist in the market. Customers can migrate within a typical onboarding cycle (weeks, not quarters). |
Under all four Article 31(2) criteria the conclusion is negative — Glassbreak does not meet the CTPP designation threshold and we expect ESMA, EBA, and EIOPA's Joint Oversight Forum to reach the same view. Should a customer's competent authority disagree, please reach out so we can align documentation.
The five DORA pillars — our supplier-side evidence
Pillar 1: ICT risk management (Article 5–16)
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| Art. 6 | ICT risk-management framework documented and approved | Partial | Information Security Policy at /policies/information-security; Risk Treatment Plan at /policies/risk-treatment-plan. Framework documented; formal annual board approval cadence not yet in place at current entity size. |
| Art. 8 | Identification and classification of ICT-supported business functions, assets, and dependencies | Met | OpenTofu provides an authoritative inventory of cloud assets; per-vertical sub-processor inventory at /legal/sub-processors. Business-function map in docs/architecture.md. |
| Art. 9 | Protection and prevention — confidentiality, integrity, availability | Met | AES-256-GCM, TLS 1.2+, Argon2id, hybrid PQ wrapping, MFA, rate limiting, signed double-submit CSRF, end-to-end encryption for customer content. See /technology/encryption. |
| Art. 10 | Detection — anomalies, network behaviour, security events | Met | Grafana Cloud + Loki log ingestion + three SLO alerts + synthetic monitoring from three regions. Daily security-snapshot probes the entire stack. |
| Art. 11 | Response and recovery — business continuity policy, communication plans, response procedures | Met | Full BCMS coverage at /trust/iso-22301: 22 DR scenarios, RTO/RPO per surface, customer-notification SLAs. Multi-cloud topology removes the largest concentrated dependency. |
| Art. 13 | Learning and evolving — post-incident reviews | Met | Post-incident review template at /policies/incident-response §11; DR-scenario failures auto-open corrective-action tickets at /policies/cadences/remediation-slas; nonconformities surface in the daily snapshot. |
| Art. 14 | Communication of crisis information | Met | Public status page at /status reflects live per-vertical health. Crisis-comms template at /policies/procedures/customer-notification with documented SEV-1/2/3/4 SLAs. |
Pillar 2: ICT-related incident management (Article 17–23)
Financial entities report major ICT-related incidents to their competent authority on a tight cascade. Where a Glassbreak incident contributes to a customer's reportable event, we align our notification timing to support their obligation.
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| T+1 hour | Initial customer notification for SEV-1 | Met | Sufficient for the customer to begin their initial 4-hour notification to the competent authority. |
| T+24 hours | Initial impact assessment shared | Met | Aligned with the customer's intermediate report to the competent authority (within 72 hours under the RTS). |
| T+30 days | Final post-mortem with root cause, impact, mitigations | Met | Aligned with the customer's final report timing. |
Pillar 3: Digital operational resilience testing (Article 24–27)
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| Art. 24 | Risk-based testing programme — vulnerability assessments, scenarios, penetration tests | Partial | Vulnerability scanning continuous; 22 scripted DR scenarios run nightly; coordinated-disclosure programme at /trust/disclosure. Independent penetration test scheduled annually once SOC 2 work begins. |
| Art. 25 | Tests of ICT tools and systems | Met | Schemathesis OpenAPI fuzz suite + Wycheproof vectors in CI on every PR. Frame-encryption + key-rotation tests in the integration suite. |
| Art. 26–27 | Threat-led penetration testing (TLPT) | N/A | TLPT applies to financial entities themselves under Article 26. Customers performing TLPT can include Glassbreak surfaces in their scope under our standard test-window approval process — write to security@glassbreak.io to coordinate. |
Pillar 4: ICT third-party risk (Article 28–30)
This is the pillar that applies most directly to Glassbreak as the supplier. Customers are required to maintain policies and contractual provisions covering us; this section is the source material for their compliance work.
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| 30(2)(a) | Clear and complete description of all functions and ICT services provided | Met | Service description in our Master Services Agreement, with surface inventory and SLAs at /trust/iso-22301. |
| 30(2)(b) | Locations where ICT services are provided, data processing locations | Met | Per-vertical region disclosure: glassbreak.io served from Fastly POPs globally; processing in AWS eu-west-2 / us-east-1 and Scaleway fr-par. Sub-processor list at /legal/sub-processors notes processing region per sub-processor. |
| 30(2)(c) | Service level descriptions including updates and revisions | Met | SLAs documented per surface at /trust/iso-22301 with RTO/RPO commitments. Change-management process in /policies/sdlc. |
| 30(2)(d) | Whether sub-contracting of critical or important functions is permitted | Met | Permitted only via published sub-processor list at /legal/sub-processors; 14 days prior notification of additions/changes. Customer right to object documented in the DPA. |
| 30(2)(e) | Cooperation with competent authorities and resolution authorities | Met | Standard DPA clause: cooperation with competent and resolution authorities where the customer is required to provide information. |
| 30(2)(f) | Termination rights and notice periods | Met | Termination rights aligned to Article 28(7): customer may terminate on material breach, on significant change of supplier ownership, on supplier insolvency, on regulator-mandated termination. Notice periods in the MSA. |
| 30(2)(g) | Conditions for participation in ICT-security awareness programmes | Met | Customer security teams may include Glassbreak in their internal awareness programmes (drills, tabletops, phishing simulations targeting our integration points) by coordination with security@glassbreak.io. |
| 30(3)(a) | Full service-level descriptions with quantitative and qualitative performance targets | Met | RTO/RPO targets per surface; uptime targets per vertical; incident-notification SLAs (above). |
| 30(3)(b) | Notice periods and reporting obligations for ICT services that may affect customers | Met | Material configuration changes communicated via the in-product changelog with at least 14 days notice; emergency security changes communicated immediately via the customer-notification path. |
| 30(3)(c) | Implementation of contingency plans, ICT security measures, and adherence to standards | Met | Standards alignment documented across /trust pages (SOC 2, ISO 27001, ISO 22301, NIS2). Contingency plans at /policies/bcp. |
| 30(3)(d) | Participate and cooperate in TLPT (where applicable) | Met | Where a financial-entity customer is required to perform TLPT covering Glassbreak as a critical ICT supplier, we will participate under a coordinated test plan and pre-agreed scope. |
| 30(3)(e) | Right of access, inspection, and audit by the financial entity and the competent authority | Met | Audit rights granted in the DPA addendum: customer-led audits with reasonable notice, or reliance on Glassbreak's published trust evidence + (when issued) SOC 2 Type II and ISO 27001 reports for routine annual review. |
| 30(3)(f) | Exit strategies — orderly transition without disruption | Met | Standard exit plan: 90-day cooperation window; full data export (encrypted bundle including secrets, contacts, message archive, audit log); confirmation of irreversible deletion of customer data after handover. |
Pillar 5: Information sharing (Article 45)
DORA encourages voluntary cyber-threat-information sharing between financial entities. As a supplier we participate indirectly via:
- Public security timeline (post-mortems on resolved incidents).
- Coordinated-disclosure programme at /trust/disclosure — findings reported here, fixed, and published.
- Sub-processor-incident notifications passed through to customers within the relevant SLA.
Register of Information — Article 28(3)
Financial entities must maintain a Register of Information (RoI) covering all ICT third-party arrangements, including a defined set of 15 fields per arrangement (under the RTS for Article 28(9)). The data Glassbreak provides for inclusion in the customer's RoI:
- Legal-entity identifiers (LEI) where applicable.
- Functions provided + classification as critical / important / supportive.
- Service start date, latest contract date.
- Processing locations + sub-processor list.
- Substitutability assessment (above).
- Tier in the customer's own classification (typically Tier 2 — important but substitutable).
A populated RoI extract is available on request to compliance@glassbreak.io.
If you are a financial entity onboarding Glassbreak and need an Article 30-aligned addendum to the standard MSA, or a populated Register of Information extract, write to compliance@glassbreak.io with your LEI and the competent authority you are reporting to.