Direct Answer
The EU Digital Operational Resilience Act (DORA) came into force on 17 January 2025, applying to all EU financial entities — banks, insurance undertakings, investment firms, payment institutions, and crypto-asset service providers — and to their critical ICT third-party service providers. DORA’s architectural requirements are not abstract: it mandates a documented ICT risk management framework, a formal Register of Information mapping every ICT dependency, a resilience testing programme including Threat-Led Penetration Testing (TLPT) for significant firms, and ongoing third-party risk management.
Sparx EA is where the DORA compliance architecture lives. The ICT service landscape — every critical application, cloud service, and data centre — is documented as Application Components with DORA-specific tagged values (asset classification, provider, RTO/RPO, resilience tier). The Register of Information structure is built directly in the EA repository. EA GraphLink connects that repository to supervisory reporting outputs, ensuring the Register stays current as the ICT estate evolves, rather than becoming a snapshot that diverges from reality the moment it is submitted.
Key Takeaways
- DORA applies to all EU financial entities from January 2025 — the Register of Information, ICT risk framework, and resilience testing requirements are regulatory obligations, not best practice.
- The Register of Information is an architecture deliverable: a complete, maintained mapping of every ICT service to its provider, classification, and dependencies. Sparx EA is the appropriate repository for this.
- MDG tagged values on Application Components carry DORA-required attributes (asset classification, third-party flag, RTO, RPO, resilience tier) — enabling automated Register generation without manual spreadsheets.
- EA GraphLink connects the Sparx EA DORA architecture to supervisory reporting processes — maintaining the Register as a live document rather than a static submission artefact.
- The Amplify engagement delivers a DORA compliance architecture practice: the ICT landscape model, the Register structure, the resilience topology, and the third-party risk register.
DORA’s Architectural Requirements
What DORA Mandates
DORA establishes five interconnected pillars of digital operational resilience, each with architecture implications:
ICT Risk Management Framework — financial entities must establish and maintain a comprehensive ICT risk management framework as part of their overall risk management. The framework must identify, classify, and document ICT assets and their functions, map dependencies between ICT assets and business functions, and assess the impact of ICT disruptions on business operations. This is a structured architecture documentation requirement.
ICT Incident Classification and Reporting — DORA defines a classification scheme for ICT incidents (major incident classification triggers mandatory reporting to competent authorities within defined timeframes). Financial entities must document the ICT topology — which systems, when disrupted, constitute a major incident trigger — to enable rapid and accurate incident classification.
Digital Operational Resilience Testing — financial entities must test the digital operational resilience of their ICT systems annually at minimum. Significant firms (defined by size and systemic importance) must conduct Threat-Led Penetration Testing (TLPT) at least every three years. TLPT requires a complete threat intelligence-informed scope — which means the threat surface (ICT landscape) must be architecturally documented for testing teams to scope effectively.
ICT Third-Party Risk Management — financial entities must manage ICT risk arising from third-party providers, including cloud service providers, software vendors, and outsourcing arrangements. A key requirement is a formal Register of Information covering all ICT third-party dependencies, updated whenever the ICT arrangement changes. The Register must be submitted to competent authorities on request.
Information Sharing — financial entities are encouraged (and in some circumstances required) to share information on cyber threats with peers through approved information sharing arrangements. Participation in threat intelligence sharing requires documented understanding of which ICT assets are relevant to which threat types.
The Register of Information
The Register of Information is DORA’s most architecture-intensive requirement. Under Article 28 of DORA, financial entities must maintain a complete register of all contractual arrangements with ICT third-party service providers. The European Supervisory Authorities (EBA, EIOPA, ESMA) have published detailed templates specifying the mandatory data fields — running to over 40 attributes per ICT arrangement.
Key Register fields include: the financial entity’s LEI (Legal Entity Identifier), the ICT third-party provider’s LEI, the type of ICT service (cloud, software, data, communication), the criticality classification of the service, the countries where the service is provided and data is stored, the contractual arrangement start and end dates, the substitutability assessment, and the impact assessment of non-availability.
The Register is not a one-time submission. DORA requires it to be kept up to date. Every new cloud service contract, software licence, or outsourcing arrangement that constitutes an ICT third-party dependency must be added. Every expired arrangement must be removed. Every change in criticality classification must be reflected. This is an ongoing architecture maintenance obligation — and a model that lives in Sparx EA and connects to reporting via EA GraphLink is far better suited to this than a manually maintained spreadsheet.
TLPT: Threat-Led Penetration Testing
TLPT under DORA Article 26 applies to significant financial entities — those meeting specific size and systemic importance thresholds set by competent authorities. The TLPT requirement mandates red-team exercises that simulate real-world threat actor tactics against production ICT systems, based on threat intelligence specific to the entity and its sector.
TLPT requires a defined scope — the set of critical ICT systems and functions included in the test. The scope must be agreed with the competent authority. This scoping exercise requires precisely the kind of ICT landscape documentation that Sparx EA provides: which applications are critical, which process critical business functions, which have cross-border or cross-entity dependencies, and which are provided by ICT third parties. Without an authoritative ICT landscape model, TLPT scope definition becomes a manual, error-prone research exercise.
Sparx EA: Building the DORA Compliance Architecture
ICT Service Landscape Documentation
The foundation of the DORA architecture in Sparx EA is the ICT service landscape: every application, cloud service, data centre, and ICT third-party arrangement that is in scope for DORA.
Each ICT asset is modeled as an ArchiMate Application Component (for software applications and cloud services) or Technology Node (for infrastructure). The DORA MDG profile adds the following tagged values to every in-scope ICT asset:
DORA Asset Classification — the ICT asset type per the ESA classification taxonomy: Application Software, Cloud Service (IaaS / PaaS / SaaS), Communication Network, Hardware, Data, or Managed Service.
Provider — the name and LEI of the ICT third-party provider (if applicable). Internal systems are marked as internally provided.
Third-Party Flag — boolean. Triggers the Register of Information data collection workflow for that asset.
Business Criticality — the criticality classification per the entity’s own ICT risk framework: Critical (loss of availability constitutes a major ICT incident) | Important (loss affects business operations but does not trigger major incident classification) | Standard.
RTO (Recovery Time Objective) — the maximum tolerable period of disruption to this ICT service, in hours. Part of the business continuity documentation required by DORA’s ICT risk management framework.
RPO (Recovery Point Objective) — the maximum tolerable data loss for this ICT service, in hours. Part of the data backup and recovery architecture documentation.
Resilience Tier — the resilience architecture tier: Tier 1 (active-active, no planned downtime), Tier 2 (active-passive, near-instant failover), Tier 3 (warm standby, recovery within RTO), Tier 4 (cold standby, manual recovery).
TLPT Scope Flag — boolean. Marks ICT assets included in the TLPT scope agreed with the competent authority.
Data Residency — the country or countries where data processed by this ICT service is stored. Required for the Register of Information.
DORA Register of Information Structure
The Register of Information is modeled in Sparx EA as a structured package containing:
- ICT Arrangements — each contractual arrangement with an ICT third-party provider is modeled as a Requirement element (using the Requirements package) with tagged values mapping to the mandatory ESA Register fields. The Requirement is linked to the Application Components and Technology Nodes that it covers.
- Provider Entities — each ICT third-party provider is modeled as an Actor element with LEI, country of incorporation, and group parent tagged values. Association relationships connect the Provider Actor to the ICT Arrangement Requirements.
- Financial Entity Entities — for groups with multiple regulated entities, each entity subject to DORA is modeled with its LEI, entity type, and competent authority. The intra-group ICT arrangements are modeled separately from third-party arrangements.
This structure means the Register of Information can be generated from the EA repository by querying the tagged values on ICT Arrangements, their linked ICT assets, and their linked Provider entities. The ESA-mandated data template can be populated from EA GraphLink queries — no manual data entry from a separate spreadsheet required.
Business Continuity Architecture: Failover Topology
DORA’s ICT risk management framework requires documentation of business continuity arrangements, including backup systems, failover procedures, and recovery architecture. In Sparx EA, the failover topology is modeled in the ArchiMate Technology layer:
- Technology Nodes represent the infrastructure components: primary data centre, secondary data centre, cloud availability zones, edge locations.
- Infrastructure Services represent the hosting and connectivity services (colocation, cloud IaaS, WAN connectivity).
- Assignment relationships connect Application Components to Technology Nodes, documenting where each application runs.
- Redundancy relationships (modeled as ArchiMate Serving relationships with a «Failover» stereotype) connect primary to secondary nodes, annotated with failover trigger type (automatic, semi-automatic, manual), failover time, and last tested date.
The combination of Application Component (with RTO/RPO tagged values) and Technology layer failover topology gives the DORA-required business continuity architecture in a single governed repository — connected across layers, not spread across separate documents.
Third-Party Risk Register
The third-party risk management requirements of DORA are implemented in Sparx EA through a Requirements package containing ICT risk assessments. Each critical ICT third-party arrangement has an associated set of risk assessment elements:
- Concentration Risk Assessment — assessing whether excessive dependence on a single ICT third-party provider creates systemic risk.
- Substitutability Assessment — the time and cost required to substitute an alternative provider if the current provider fails or exits the market.
- Sub-outsourcing Chain Assessment — documenting the ICT third-party provider’s own significant sub-processors (the supply chain below the direct provider).
- Exit Strategy Assessment — the documented exit strategy for each critical ICT arrangement, including data portability provisions and transition service arrangements.
These risk assessment elements are linked to their ICT Arrangement and Provider Actor elements through trace relationships — creating a complete third-party risk architecture in the EA repository.
MDG Design: The DORA Compliance Stereotype Profile
The DORA MDG profile defines the following stereotypes for use across the Sparx EA DORA architecture:
«DORA-ICTAsset» — applied to Application Components and Technology Nodes. Tagged values: AssetClassification, Provider, ProviderLEI, ThirdPartyFlag, BusinessCriticality, RTOhours, RPOhours, ResilienceTier, TLPTScopeFlag, DataResidency, ContractReference.
«DORA-ICTArrangement» — applied to Requirement elements representing contractual arrangements. Tagged values: ArrangementType, CriticalityClassification, SubstitutabilityRating, ContractStartDate, ContractEndDate, NoticePeriod_months, ExitStrategyDocRef.
«DORA-Provider» — applied to Actor elements representing ICT third-party providers. Tagged values: ProviderLEI, ProviderCountry, ProviderGroupParent, ProviderGroupParentLEI, ProviderType (enumeration: Cloud | Software | Data | Communication | Managed | Other).
«DORA-Failover» — applied to ArchiMate Serving relationships in the Technology layer representing failover arrangements. Tagged values: FailoverType (enumeration: Automatic | Semi-automatic | Manual), FailoverTime_hours, LastTestedDate, TestResultRef.
This stereotype profile is the MDG technology deliverable — an XML file that, when loaded into Sparx EA, makes all DORA-required metadata attributes available through the standard Sparx EA stereotype picker and tagged values panel.
EA GraphLink: DORA Register as a Live Document
DORA’s ongoing maintenance requirement for the Register of Information is where EA GraphLink provides its most distinctive value. A Register maintained in a spreadsheet becomes stale the moment a new cloud service is contracted or an existing arrangement expires. A Register generated from the EA repository via EA GraphLink is always current — because the repository is the system of record for the ICT landscape, and it is updated as a matter of normal architecture governance.
EA GraphLink connects the Sparx EA DORA repository to:
Power BI — a DORA compliance dashboard showing: Register coverage (percentage of ICT assets with complete Register data), third-party risk heat map (concentration by provider, by geography, by service type), resilience tier distribution across the critical ICT asset portfolio, RTO/RPO gap analysis (assets where recovery objectives are not met by current failover architecture), and TLPT scope completeness.
Supervisory Reporting — EA GraphLink’s GraphQL API can be queried by reporting tools to extract the Register of Information in the ESA-mandated template format. When a competent authority requests the Register, the response is generated from the live repository — not from a file that may be months out of date.
Third-Party Review Workflow — tagged values on ICT Arrangements with approaching contract end dates (within 90 days, flagged by ContractEndDate query) surface in Power BI as a contract renewal action list — ensuring the DORA annual review obligation is embedded in a workflow rather than managed through calendar reminders.
FAQ
Q1: Does DORA apply to non-EU financial entities?
DORA’s primary scope is financial entities that are authorised or registered under EU financial services legislation — which means EU-based banks, insurers, investment firms, payment institutions, and others. However, DORA also applies to ICT third-party service providers that are deemed critical to EU financial entities, regardless of where those providers are incorporated. A US or UK cloud provider that serves multiple EU-regulated financial entities can be designated a Critical ICT Third-Party Provider by the European Supervisory Authorities and subjected to DORA oversight. Non-EU financial institutions that provide services to EU clients through EU branches or subsidiaries are subject to DORA for those operations.
Q2: What is the Register of Information and when must it be submitted?
The Register of Information is the mandatory register of all contractual arrangements with ICT third-party service providers, specified under Article 28 of DORA. It must be maintained on an ongoing basis and submitted to the relevant competent authority on request — or as part of the periodic supervisory reporting cycle as defined by national competent authorities. The European Supervisory Authorities (EBA, EIOPA, ESMA) have published detailed Register templates covering over 40 mandatory data fields per ICT arrangement. DORA also requires financial entities to report any new ICT third-party arrangements with critical or important functions within a defined timeframe. The Register is not a one-time submission — it must reflect the current ICT third-party landscape at all times.
Q3: How does Sparx EA handle the multi-entity structure typical of financial groups?
Financial groups typically have multiple regulated entities — a banking subsidiary, an insurance subsidiary, a payment institution, and others — each individually subject to DORA. In Sparx EA, each legal entity is modeled as an Actor with its LEI and DORA scope status. ICT assets can be assigned to specific entities (an application used only by the banking subsidiary) or modeled as shared (infrastructure used by multiple entities). Intra-group ICT arrangements — where one group entity provides ICT services to another — are modeled separately from external third-party arrangements. The DORA Register query can filter by entity, producing entity-specific Register outputs from a single consolidated EA repository.
Q4: What does TLPT require architecturally and how does Sparx EA support TLPT scoping?
TLPT (Threat-Led Penetration Testing) under DORA Article 26 requires a defined scope of critical ICT systems to be agreed with the competent authority before testing begins. The scope must be threat intelligence-informed — meaning it should reflect the actual threat landscape for the institution, not just a generic selection of systems. Sparx EA supports TLPT scoping by providing the ICT landscape model with TLPTScopeFlag tagged values, allowing testers and risk managers to work from the EA repository to identify critical ICT assets, their interconnections, and their third-party dependencies. The scope definition document produced for the competent authority is generated from EA repository queries — ensuring it reflects the actual ICT landscape rather than an outdated manual inventory.
Q5: How do we maintain the DORA architecture as our ICT estate changes?
Maintenance of the DORA architecture in Sparx EA is an ongoing governance obligation, not a one-time project delivery. Sparx Services recommends establishing an ICT change advisory process where any new cloud service contract, software procurement, or infrastructure change triggers an update to the EA repository — specifically adding the new ICT asset, creating the corresponding ICT Arrangement element with Register data, and updating the third-party provider record. EA GraphLink’s Power BI dashboard provides a Register completeness metric that flags any ICT assets that have been added to the portfolio but not yet populated with full DORA Register data — closing the governance loop. The Amplify engagement from Sparx Services includes the establishment of this ongoing governance capability.
Q6: What is the relationship between DORA and the EBA outsourcing guidelines?
DORA supersedes and broadens the earlier EBA Guidelines on Outsourcing Arrangements (EBA/GL/2019/02) for in-scope financial entities. The EBA outsourcing guidelines required documentation of material outsourcing arrangements, risk assessments, and exit strategies — DORA extends these requirements to all ICT third-party arrangements (not just those classified as material outsourcing), adds specific resilience testing obligations, and introduces the ICT third-party risk management framework and TLPT requirements. Financial entities that had already implemented EBA outsourcing architecture in Sparx EA will find that their existing application portfolio and third-party documentation provides a strong foundation — but will need to extend it with DORA’s additional required fields and the resilience topology.
Q7: Can Sparx EA generate the ESA-mandated Register template directly?
The ESA Register templates are structured tabular formats (Excel-compatible). Via EA GraphLink’s GraphQL API, the DORA ICT Arrangement elements in Sparx EA — with their full tagged value set — can be queried and exported in a format that populates the ESA template fields. This is not a fully automated one-click export but a supported data extraction workflow: EA GraphLink queries the repository, returns structured JSON, and a transformation layer (Power Query in Power BI, or a custom script) maps the fields to the ESA template columns. Sparx Services configures this extraction workflow as part of the DORA architecture engagement — eliminating the manual data assembly that would otherwise be required at each supervisory reporting event.
Q8: What engagement does Sparx Services recommend for DORA compliance architecture?
Amplify is the right engagement for organisations that need to build a DORA compliance architecture practice — not just produce a one-time Register but establish the ongoing governance capability that DORA requires. Amplify delivers the ICT landscape model with full DORA MDG stereotype profile, the Register of Information structure, the business continuity and failover topology, the third-party risk register, and the EA GraphLink connection to Power BI and supervisory reporting outputs. For organisations that need to assess their current-state ICT documentation before beginning the DORA architecture work, Discover provides the ICT landscape inventory that Amplify then structures. Amplify pricing starts from $45,000.
Work With Sparx Services
DORA compliance is not a one-time project — it is an ongoing architecture obligation. Sparx Services’ Amplify engagement builds your DORA compliance architecture practice in Sparx EA: the ICT service landscape, the Register of Information, the resilience topology, and the third-party risk register — connected to supervisory reporting via EA GraphLink so your Register stays current as your ICT estate evolves.
Amplify from $45,000. Contact us to discuss your DORA compliance architecture.
