Governance and Policy ManagementDORA Readiness for GCC Banks with EU Operations
DORA is an EU regulation, so many Gulf banks assume it stops at the EU’s border. For a group with an EU authorization, it does not. Complyan’s DORA implementation guide covers the regulation’s structure. This piece covers how it reaches a GCC banking group, what each EU entity must hold on its own, and a plan to get ready.
A GCC banking group can run much of its technology from Riyadh, Dubai or Kuwait and still have a European entity carrying the regulatory responsibility for that technology.
That is where DORA becomes complicated.
The Digital Operational Resilience Act has applied since 17 January 2025 and establishes ICT risk-management requirements for EU financial entities. Its scope covers financial entities such as credit institutions and investment firms. Critical ICT third-party providers can also become subject to the EU oversight regime.
For GCC groups, the first task is therefore not to apply DORA across every entity.
It is to determine which European legal entities are subject to the regulation and then identify the systems, suppliers and group functions those entities rely on.
A European bank subsidiary may depend on infrastructure operated by the GCC parent. Its security monitoring may sit in a regional SOC. Procurement may also be managed centrally..
How DORA Reaches a GCC Banking Group
Route | What it means | Source |
EU subsidiary authorized in a Member State | In scope for its EU activities, whatever the parent’s nationality | Regulation DORA |
EU branch of a GCC bank | The European Commission confirmed on 17 December 2025 that DORA applies to third-country branches if the head office would qualify as an entity listed in Article 2(1)(a) to (t) in its home country | |
Group services used by an EU entity, such as a SOC or hosting contract | Intra-group ICT arrangements are captured in the register and must meet Article 30 contract requirements | Fintech Passport, Regulation DORA |
Group Compliance Is Not a Substitute
A common assumption is that a Gulf head office can run one group DORA program and have its EU entities inherit it. Regulation DORA states that each in-scope EU subsidiary must be able to demonstrate its own ICT risk-management framework, its own register of information, its own incident-reporting capability, and its own testing, even when much of it is delivered centrally. Group tooling helps. Group-level compliance as a substitute does not exist.
The same analysis notes that for a non-EU group, the national law of the Member State whose authority supervises the EU entity governs penalties, because Article 50 sets no EU-wide maximum fine for financial entities. It also flags that the “2 percent of annual turnover” figure often attached to DORA comes from NIS2, not DORA.
The Five Pillars, Read From the Gulf
Pillar | What the EU entity needs | Effect on a Gulf group |
ICT risk management (Articles 5 to 16) | Its own framework, with management body accountability | Group policies can seed it, but the EU board owns it |
Incident reporting (Articles 17 to 23) | Its own capability for the 4-hour, 72-hour, and one-month reporting clocks | A SOC in the Gulf that detects an incident must route it to the EU entity in time |
Resilience testing (Articles 24 to 27) | A testing program, with threat-led penetration testing where it applies | SIDD notes group systems are often in scope and must be made available for testing |
Third-party risk (Articles 28 to 44) | A register, compliant contracts, and exit plans | Parent-to-subsidiary contracts must still meet Article 30 |
Information sharing (Article 45) | Voluntary threat intelligence exchange | Group intelligence can feed it |
The incident clocks come from Regulation DORA’s summary of Articles 17 to 23, so confirm the exact start points against the technical standards before finalizing your procedures.
The Register of Information: Where Groups Trip
Article 28(3) requires a register of all contractual arrangements for ICT services, kept at entity, sub-consolidated, and consolidated levels, using the ESAs’ templates under Commission Implementing Regulation (EU) 2024/2956, per SIDD and Kopik. Three points matter for a GCC group.
Intra-group services count: Kopik, citing the ESAs’ register FAQ of 14 February 2025, explains that an EU entity in a third-country group with no EU parent reports on an individual basis, and other group entities that provide it with ICT services are reported as intra-group providers.
Consolidated scope is broad: an EBA Q&A states that sub-consolidated and consolidated registers should reflect all financial entities and branches within the consolidation scope.
Criticality needs tagging: mark which group-run services support the EU entity’s critical or important functions, because that classification drives contract terms and exit planning.
DORA Changes What “Approved Vendor” Means
A provider passing due diligence does not complete the third-party requirement.
DORA treats ICT third-party risk as part of the financial entity’s ICT risk-management framework. The regulation expects ongoing management of arrangements supporting critical or important functions.
This includes monitoring and contractual governance.
Exit planning also matters.
A critical service provider can be secure and still create unacceptable concentration risk when the bank cannot replace the service within an acceptable period.
That issue becomes more important for GCC groups using common providers across Europe and the Middle East.
A single cloud platform may support several regulated entities.
The bank therefore needs both vendor-level risk and a group view of dependency.
What a Supervisor May Ask to See
This list is practical guidance, not a supervisory checklist:
The current register: complete, in the required template, and updated when a contract changes.
An incident timeline from a rehearsal: showing how a Gulf-detected event reaches the EU entity’s decision-maker.
Test results: including how group systems were made available for any threat-led test.
Signed intra-group contracts: with the Article 30 terms in place.
Management body minutes: showing the EU board reviewed ICT risk and approved the framework.
Six Steps to Readiness
Map the EU exposure: list every EU-authorized entity and branch, and every service each one receives from the group or from outside providers.
Confirm scope with counsel and the supervisor: the national authority’s rules apply to each entity, so record the conclusion for each one.
Build the entity-level register, including group providers: Complyan’s third-party risk management keeps contracts, services, criticality, and assessments attached to each provider, group or external.
Stand up the ICT risk framework and board reporting: Complyan’s cyber risk management platform holds the risk record, and Complyan’s executive and board reporting shows the EU management body its current position.
Route incidents and keep the evidence: write the path from a Gulf SOC alert to the EU entity’s reporting decision, then rehearse it. Complyan’s audit and compliance management platform keeps the timeline and approvals mapped to controls.
Map once across home frameworks: GCC banks already carry regional requirements. Baker Tilly’s summary of CBK CORF lists a Third-Party Risk Management baseline, and Complyan’s SAMA guide covers Saudi Arabia’s framework. Complyan’s cybersecurity compliance tools map one control and its evidence across DORA and those frameworks, so teams collect it once.
DORA Should Sit Alongside GCC Banking Frameworks
False precision: a score of 73.4 implies accuracy the inputs cannot support, so report bands with the
DORA should not become another independent compliance stack.
GCC banking groups may already operate controls for SAMA, CBK, NCA ECC, CBUAE requirements or ISO 27001.
Many underlying controls can support multiple obligations.
Access reviews can be mapped. Incident-response testing may support several frameworks. Vendor assessments can also be reused where the evidence meets each requirement.
Complyan already supports regional frameworks alongside international standards in a common control environment.
Complyan’s existing DORA implementation guide also covers the wider regulation and its implementation requirements.
The advantage for GCC banks is that DORA can be added to an existing control structure rather than creating another evidence programme from zero.
reasons behind them.
Ratings without context: an external rating cannot see which vendors hold your sensitive data, so combine it with inherent risk.
One-time calibration: weights set at launch drift as the vendor base changes, so revisit them on a schedule.
No feedback loop: record every time an analyst overrides a score and why, because frequent overrides show the model needs adjusting.
To measure whether the model works, track onboarding time by tier, the share of reassessments completed on schedule, and the override rate. These measures are practical guidance, and they show leadership what the scoring program delivers.
Conclusion: DORA Readiness Is a Group Coordination Problem
For a GCC bank with EU operations, DORA compliance may sit with a European legal entity while much of the technology required to prove compliance sits elsewhere.
That creates a governance problem before it becomes a technical one.
The bank needs clear entity scope and mapped ICT dependencies. Vendor records need to be current. Resilience testing must produce evidence. Incident reporting cannot depend on slow communication across the group.
Complyan brings DORA and GCC cybersecurity frameworks into the same GRC environment so common controls can be reused while regulatory ownership remains clear.
The strongest DORA programme is therefore not the one with the largest control library.
It is the one where the EU entity can prove that its critical services remain resilient even when the people or systems supporting them sit thousands of kilometres away.
Frequently Asked Questions About Vendor Risk Scoring
Does DORA apply to every GCC bank with European customers?
No. DORA scope depends on the relevant financial entity and its regulatory status in the EU. Serving EU customers alone does not automatically place the entire GCC group under DORA.
What is the DORA Register of Information?
It is the structured record of ICT third-party contractual arrangements that in-scope financial entities must maintain and keep current.
Can SAMA or CBK controls be reused for DORA?
Yes, where the same internal control satisfies both requirements. The mapping should still document any additional DORA obligations.
Why is DORA third-party risk important for GCC groups?
EU entities can depend heavily on technology and service providers managed by the GCC parent. DORA requires those ICT dependencies to remain visible and governed even when the provider relationship is managed elsewhere in the group.