DORA ICT Risk Management Tools: EU-Native Alternatives for Articles 5–16 Compliance 2026

Post #1319 in the sota.io EU Cyber Compliance Series

The Digital Operational Resilience Act (DORA) has been fully applicable since January 17, 2025. Articles 5 through 16 define a comprehensive ICT Risk Management Framework that every bank, insurer, and investment firm in the EU must maintain. The framework requires a living ICT risk register, continuous monitoring, documented mitigation measures, and board-level accountability.

Financial institutions have rushed to implement this framework — and most reached for the tools they already had: ServiceNow IT Risk Management, IBM OpenPages, MetricStream, and similar enterprise GRC platforms. These tools are the operational backbone of DORA compliance across European finance.

There is a problem. Every one of these platforms is headquartered in the United States.

Your DORA ICT Risk Register — which documents every identified vulnerability, every security gap, every pending mitigation measure across your entire technology stack — runs on infrastructure owned by a US-based corporation subject to the CLOUD Act (18 U.S.C. § 2713). The Department of Justice can compel production of that data regardless of where the servers physically sit.

This is not a theoretical risk. It is a structural contradiction at the heart of DORA compliance: the regulation designed to protect European financial infrastructure generates evidence that lives under US legal jurisdiction.

What DORA Articles 5–16 Actually Require

Before evaluating tools, it is worth being precise about what the ICT Risk Management Framework demands. The requirements are granular.

Article 5 — Governance and Organisation

The management body (board of directors or equivalent) is directly accountable for ICT risk. This cannot be delegated to IT or compliance functions alone. The board must approve the ICT risk management framework, receive regular reports, and allocate sufficient budget for ICT resilience.

Article 6 — ICT Risk Management Framework

Financial entities must have a documented, comprehensive ICT risk management framework that:

• Covers all ICT assets (hardware, software, data, communication systems)
• Identifies and classifies ICT risks on a continuous basis
• Documents the information assets that support critical functions
• Is reviewed at least annually (or after major ICT incidents)

Articles 7–8 — Identify and Protect

Entities must maintain an up-to-date register of all ICT assets supporting critical or important functions. This includes hardware inventory, software license management, and network topology documentation. Logical and physical access controls must be documented and enforced.

Article 9 — Detection

Continuous monitoring mechanisms must detect anomalous activity across ICT systems. This encompasses SIEM integration, log aggregation, and alerting on deviations from established baselines.

Articles 10–12 — Response and Recovery

ICT business continuity plans must exist for critical functions, with documented recovery time objectives (RTOs) and recovery point objectives (RPOs). Annual testing of these plans is mandatory.

Articles 13–16 — Learning, Communication, and Updates

Post-incident reviews must feed back into the ICT risk management framework. The framework must be updated when new risk information emerges, when supervisory authorities issue guidance, or after major incidents at peer institutions.

What This Means in Practice

Running this framework requires, at minimum:

• An ICT asset inventory / CMDB that tracks all hardware and software
• A risk register linking assets to identified risks and mitigation status
• A GRC / IRM platform for workflow, approvals, and board reporting
• A BCM platform for continuity planning and testing documentation
• SIEM / monitoring integration for the detection layer

Each layer has established enterprise vendors. Most are US-based.

The US Tool Landscape: CLOUD Act Exposure Scores

ServiceNow IT Risk Management

Headquarters: Santa Clara, California, USA Parent: ServiceNow, Inc. (NYSE: NOW)

ServiceNow IRM is the dominant platform for enterprise ICT risk management in European financial services. When EBA and EIOPA publish DORA implementation guidance, the workflows they describe map almost directly onto ServiceNow's risk register, control mapping, and issue management modules.

ServiceNow's cloud offering (Now Platform on ServiceNow-owned infrastructure or hyperscaler co-location) processes financial institutions' complete ICT risk profiles. Every identified vulnerability, every control gap, every pending remediation action, every audit finding — all of it sits on ServiceNow infrastructure.

CLOUD Act Exposure: ServiceNow, Inc. is a US corporation. The CLOUD Act requires US companies to produce data stored anywhere in the world in response to valid US legal process. ServiceNow's EU data centers do not change this legal obligation. The European Court of Justice's Schrems II ruling (2020) established that Privacy Shield was invalid specifically because of this surveillance risk — and the CLOUD Act exposure that existed then remains structurally identical today.

IBM OpenPages with Watson

Headquarters: Armonk, New York, USA Parent: IBM Corporation (NYSE: IBM)

IBM OpenPages is the other major incumbent in European financial services GRC. It is particularly prevalent in large banking groups that standardized on IBM infrastructure in the 1990s and 2000s. OpenPages handles regulatory change management, operational risk management (aligned with Basel III and now DORA), and internal audit workflows.

IBM offers OpenPages both on-premises and as SaaS on IBM Cloud. IBM Cloud's EU Multi-Zone Regions (MZRs) are physically in Frankfurt and London. Physical location, however, does not resolve CLOUD Act jurisdiction: IBM Corporation is headquartered in Armonk, New York, and subject to US legal process.

The Watson Integration Risk: IBM has progressively integrated Watson AI into OpenPages for risk classification, document analysis, and control testing automation. AI-driven analysis of your DORA ICT risk data generates additional data derivatives that are processed on IBM's Watson infrastructure. The data surface for CLOUD Act requests expands with each AI integration.

MetricStream

Headquarters: Foster City, California, USA Parent: MetricStream, Inc. (private — Clearlake Capital, US PE)

MetricStream occupies the mid-market position in the financial services GRC space. It is widely deployed in European insurance companies, asset managers, and mid-tier banks. Its Financial Services Risk Management module is explicitly positioned for DORA compliance, including ICT risk register templates aligned with EBA/ESMA/EIOPA RTS.

In 2020, MetricStream was acquired by Clearlake Capital Group, a California-based private equity firm with $90 billion AUM. This ownership change reinforced its US corporate character. MetricStream's cloud offering runs primarily on AWS (US corporation) with EU region options.

The Double CLOUD Act Exposure: MetricStream (US-PE-owned, California-incorporated) runs on AWS (US corporation, headquartered in Seattle). Your DORA ICT risk data is simultaneously subject to MetricStream's corporate obligations under CLOUD Act and to AWS's obligations under the same statute. This creates layered US legal exposure.

Fusion Risk Management (Fusion Framework System)

Headquarters: Chicago, Illinois, USA Parent: Fusion Risk Management, Inc. (private — FTV Capital, US PE)

Fusion is the specialist in operational resilience and business continuity management — directly relevant to DORA Articles 10–12. Its platform manages BCM plans, crisis scenarios, business impact analyses (BIA), and recovery testing documentation. European financial institutions adopted Fusion specifically for the BCM/operational resilience layer of DORA.

Fusion runs on Salesforce infrastructure (Salesforce, Inc. — San Francisco, California, US). The ownership chain is: FTV Capital (San Francisco PE) → Fusion Risk Management, Inc. (Illinois) → Salesforce Platform (California). Three layers of US corporate jurisdiction.

The Third-Party Risk Inception Problem

DORA Article 28 requires financial institutions to manage ICT third-party concentration risk. Specifically, entities must assess whether their ICT arrangements create excessive dependency on a single third-party provider or a small number of providers.

Here is the structural irony: the tools financial institutions use to document and manage their third-party concentration risk are themselves concentrated third parties — all incorporated in the United States.

Your DORA Art. 28 third-party risk register (listing all ICT vendors, their criticality classification, contract terms, and audit findings) is stored in a system operated by a US company. The register that documents your concentration risk to US companies is itself a US-operated service.

More acutely: the ICT risk register documents the complete vulnerability map of your technology infrastructure. If the US DOJ compels ServiceNow, IBM, or MetricStream to produce this data, a foreign government gains a detailed blueprint of the security gaps in European financial infrastructure.

This is why tool selection for DORA Art. 5–16 compliance is a sovereign risk decision, not merely an IT procurement decision.

EU-Native Alternatives by Layer

Layer 1: GRC / IRM Platforms (Risk Register, Control Mapping, Board Reporting)

SAP GRC Risk Management

• Headquarters: SAP SE, Dietmar-Hopp-Allee 16, Walldorf, Germany (Baden-Württemberg)
• Legal form: Societas Europaea (SE) — EU corporate form
• Cloud infrastructure: SAP Business Technology Platform (BTP), available on Hetzner (Frankfurt) for EU-only deployment
• CLOUD Act exposure: SAP SE is German. No US parent. However, SAP has US subsidiaries (SAP America, Inc.). The critical distinction: SAP SE as the data controller under EU customer contracts is German. A CLOUD Act order to SAP America for data controlled by SAP SE would face mutual legal assistance treaty (MLAT) requirements and EU blocking statute limitations (EU Regulation 2271/96 for specific sectors).
• DORA fit: SAP GRC includes Financial Services Risk Management modules with DORA-specific templates. EBA, EIOPA, and ESMA regulatory update subscriptions are maintained.

Cura Software

• Headquarters: Cura Software B.V., Delft, Netherlands
• Legal form: Besloten Vennootschap (BV) — Dutch private company
• Cloud infrastructure: European data centers (Azure EU regions — Microsoft is US, but Cura is Dutch controller)
• CLOUD Act exposure: Cura Software B.V. is Dutch-incorporated. No US parent. The Azure infrastructure creates indirect US exposure (Microsoft CLOUD Act obligations) — but Cura as data controller is EU-incorporated, and the layered Microsoft-Cura contract structure matters for enforcement.
• DORA fit: Cura GRC has a financial services module specifically updated for DORA 2025 requirements. The platform covers ICT risk register, vendor risk management, and BCP documentation. Smaller footprint than SAP but faster implementation for mid-tier firms.

DataGuard

• Headquarters: DataGuard GmbH, Munich, Germany
• Legal form: GmbH — German private company
• Cloud infrastructure: Germany-only infrastructure (ISO 27001 certified, German data centers)
• CLOUD Act exposure: None. DataGuard GmbH is German. No US parent, no US investment that would create CLOUD Act secondary exposure. German VC-backed.
• DORA fit: DataGuard started as GDPR compliance automation and has expanded to cover ISO 27001, TISAX (automotive), and now DORA. Its strength is in the smaller financial institution segment (fintechs, payment institutions, e-money institutions) rather than tier-1 banking groups.

Layer 2: ICT Asset Management / CMDB (Articles 7–8)

DORA's requirement to maintain a register of all ICT assets supporting critical functions requires a CMDB (Configuration Management Database) integrated with the risk management layer.

Lansweeper

• Headquarters: Lansweeper NV, Ghent, Belgium
• Legal form: NV — Belgian public company (acquired by Idinvest/Eurazeo in 2022, but remains Belgian-incorporated)
• Cloud: Lansweeper Cloud runs on Azure EU regions. On-premises deployment is also available.
• DORA fit: Lansweeper's IT Asset Management platform provides the hardware/software inventory required by DORA Art. 8. Network topology visualization and software license reconciliation are built-in. Direct API integration with ServiceNow, SAP, and custom risk platforms.

i-doit (synetics GmbH)

• Headquarters: synetics GmbH, Hamburg, Germany
• Legal form: GmbH — German private company
• Deployment: Open-source core (self-hosted) + commercial subscription. No cloud obligation.
• DORA fit: i-doit is an IT documentation and CMDB platform. Financial institutions can self-host on German infrastructure (Hetzner, IONOS) with zero third-party data exposure. DORA Art. 8 asset registers can be built entirely within the EU regulatory perimeter.
• CLOUD Act exposure: Zero for self-hosted deployment. German developer, German infrastructure, open-source code base.

Layer 3: Business Continuity Management / Operational Resilience (Articles 10–12)

Everbridge (EU-hosted)

• Headquarters: Burlington, Massachusetts, USA
• EU deployment: Everbridge offers EU-region data residency on AWS Frankfurt
• CLOUD Act exposure: US parent means CLOUD Act applies regardless of EU hosting. However, Everbridge has implemented contractual GDPR addenda and EU Standard Contractual Clauses. The data residency option partially addresses supervisory requirements but not CLOUD Act access.
• Practical consideration: For BCM specifically, the information processed (crisis contact lists, escalation trees, recovery playbooks) is less sensitive than an ICT vulnerability register. The risk calculus differs from the risk register layer.

The honest assessment: there is no dominant EU-native BCM platform for the large financial institution segment. Sungard Availability Services (restructured post-bankruptcy, now focused on data centers, not GRC software) and Disaster Recovery as a Service (DRaaS) providers fill adjacent needs but do not replace BCM workflow platforms.

EU-viable approach: Many European financial institutions build BCM documentation on top of existing EU-native GRC platforms (SAP GRC, Cura) rather than deploying a standalone BCM tool. This creates a unified data environment for DORA Art. 6–16 with a single EU corporate controller.

Comparison Summary

What the EBA and ESMA Actually Require

The Joint Committee of the European Supervisory Authorities has published several Regulatory Technical Standards (RTS) under DORA that clarify tool requirements:

RTS on ICT Risk Management Framework (EBA/RTS/2024/01): This standard specifies the minimum content of ICT risk management frameworks. It does not mandate specific tools but does require that the framework documentation be "sufficiently granular" and updated "on a regular basis." The implication: documentation quality matters, and tools that support auditability (audit trails, version control, approval workflows) are preferred.

RTS on ICT-Related Incidents (EBA/RTS/2024/02): For the detection layer (Art. 9), financial entities must have tools capable of detecting anomalous activities "as soon as they occur." The SIEM/monitoring layer (separate from risk register tools) is addressed here.

Guidelines on ICT Third-Party Risk Management (EBA/GL/2025/XX): Draft guidelines published in Q1 2025 specifically address the ICT tool supply chain. While not finalized, draft language indicates that "critical ICT tools" supporting DORA compliance activities should themselves be subject to the Art. 28 third-party risk management process.

The implication: Your DORA ICT Risk Management tool may itself be in scope for DORA Art. 28 third-party risk assessment. ServiceNow, IBM OpenPages, and MetricStream would need to be registered as ICT third-party service providers in your Art. 28 framework — and their US jurisdiction would be a documented risk factor.

Practical Migration Considerations

For European financial institutions currently on US GRC platforms, a full migration is not always practical in the short term. A pragmatic approach:

Immediate (0–6 months):

1. Classify your current GRC platform as an ICT third-party provider under DORA Art. 28
2. Document the US jurisdiction risk as a formal risk item in your ICT risk register
3. Implement contractual controls: EU data residency addendum, audit rights, exit plan documentation
4. Restrict the most sensitive data in the ICT risk register (zero-day vulnerabilities, unpatched system inventories) to on-premises or EU-hosted systems

Medium term (6–18 months):

1. Evaluate EU-native GRC platforms (SAP GRC, Cura Software, DataGuard) against your specific DORA requirements
2. Migrate the ICT asset inventory to an EU-native CMDB (Lansweeper, i-doit) as an independent layer
3. Pilot DataGuard or Cura for smaller entities (fintechs, payment institutions) where the migration cost is lower

Long term (18–36 months):

1. Full migration of ICT risk register and BCM documentation to EU-native platforms
2. Unified EU data environment for all DORA Art. 5–16 documentation
3. DORA Art. 28 third-party register free of US-jurisdiction critical tools

The Regulatory Trajectory

The European Banking Authority's DORA supervisory convergence program begins in earnest in 2025–2026. As national competent authorities conduct their first DORA compliance assessments, the question of ICT tool jurisdiction will emerge as a supervisory focus point.

Two signals are worth monitoring:

Signal 1: The EU AI Act and DORA intersection. DORA Art. 6 requires that ICT risk management frameworks account for AI-based systems. As financial institutions integrate AI into risk scoring and anomaly detection, the AI processing layer (often US-based: OpenAI, Anthropic, AWS Bedrock) becomes part of the DORA ICT risk surface. This is not yet in scope for supervisory examination but will become so as the EU AI Act's financial sector provisions interact with DORA.

Signal 2: Critical ICT Third-Party Provider designations. The ESAs are conducting their first CTPP designation exercise under DORA Art. 31 in 2025–2026. If ServiceNow, IBM, or Salesforce (Fusion) are designated as CTPPs, they face direct ESA supervision — including the possibility that ESA supervisors review their CLOUD Act response procedures. This creates a feedback loop: CTPP designation forces US vendors to disclose their CLOUD Act practices to EU supervisors.

Conclusion

DORA Articles 5–16 require financial institutions to build a comprehensive, continuously maintained ICT risk management framework. The tools most commonly deployed for this purpose — ServiceNow IRM, IBM OpenPages, MetricStream — score 4–5 out of 25 on CLOUD Act exposure metrics.

This means the operational resilience documentation that European financial institutions are legally required to maintain, including their complete vulnerability inventories, control gap assessments, and pending remediation plans, sits under US legal jurisdiction.

EU-native alternatives exist across all three required tool layers:

• GRC/IRM: SAP GRC (20/25), DataGuard (23/25), Cura Software (18/25)
• CMDB/Asset Management: Lansweeper (20/25), i-doit (24/25)
• BCM: No dominant EU-native platform — integration with EU GRC tools is the current best practice

The selection of ICT risk management tools is, under DORA, not merely an IT procurement decision. It is a sovereign risk decision with direct implications for the confidentiality of your financial institution's security posture documentation.

This post is part of the sota.io EU-DORA-COMPLIANCE-TOOLS series. Next: DORA Incident Reporting Requirements — Automation & Tools 2026 (Post #1320).