DORA Compliance Architecture: Modeling Digital Operational Resilience in Sparx EA

The short version: the EU Digital Operational Resilience Act (DORA) has applied to all EU financial entities since 17 January 2025, and most of what it asks for is architecture work. It mandates a documented ICT risk management framework, a formal Register of Information mapping every ICT dependency, a resilience testing program, and ongoing third-party risk management. The most reliable way to satisfy those obligations is to treat the ICT estate as a model — every critical application, cloud service, and data center captured in Sparx EA with DORA-specific tagged values — so the Register is generated from a live system of record rather than retyped into a spreadsheet that drifts the moment it is filed.

DORA touches every EU financial entity in scope: banks, insurance undertakings, investment firms, payment institutions, and crypto-asset service providers, plus their critical ICT third-party providers. The requirements are concrete, and they map cleanly onto things an enterprise architecture practice already knows how to do: document a landscape, classify assets, trace dependencies, and keep the record current under governance.

What DORA actually asks for

DORA establishes five interconnected pillars of digital operational resilience. Each one carries an architecture implication, and most of them resolve to documenting the ICT estate well enough that the answers can be queried rather than reconstructed.

Pillar	Core requirement	Architecture implication
ICT risk management framework	Identify, classify, and document ICT assets; map dependencies to business functions; assess disruption impact.	A structured, maintained model of applications, infrastructure, and the business functions they serve.
Incident classification & reporting	Classify ICT incidents and report major ones to authorities within set timeframes.	A documented topology showing which systems, when disrupted, constitute a major-incident trigger.
Resilience testing	Test ICT systems at least annually; significant firms run Threat-Led Penetration Testing (TLPT) at least every three years.	An authoritative ICT landscape from which a threat-informed test scope can be defined.
Third-party risk management	Manage ICT risk from providers; maintain a Register of Information of all ICT third-party arrangements.	A complete, governed mapping of every ICT service to its provider, criticality, and dependencies.
Information sharing	Share cyber-threat intelligence with peers through approved arrangements.	A documented view 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, financial entities must maintain a complete register of all contractual arrangements with ICT third-party service providers. The European Supervisory Authorities (EBA, EIOPA, ESMA) published detailed templates specifying the mandatory data fields, running to more than 40 attributes per ICT arrangement. Entities first submitted the Register to their national competent authority in April 2025.

Key Register fields include the financial entity's LEI (Legal Entity Identifier), the provider's LEI, the type of ICT service (cloud, software, data, communication), the criticality classification, the countries where the service is delivered and data is stored, contract start and end dates, the substitutability assessment, and the impact of non-availability.

The Register is not a one-time submission. Every new cloud contract, software license, or outsourcing arrangement that constitutes an ICT third-party dependency has to be added; every expired arrangement removed; every change in criticality reflected. That is an ongoing maintenance obligation — and it is exactly the kind of work a governed model handles far better than a hand-maintained spreadsheet, because the model is already the system of record for the ICT landscape.

TLPT: Threat-Led Penetration Testing

TLPT under Article 26 applies to significant financial entities — those meeting size and systemic-importance thresholds set by competent authorities. It mandates red-team exercises that simulate real-world threat-actor tactics against production ICT systems, informed by threat intelligence specific to the entity and its sector.

TLPT requires a defined scope: the set of critical ICT systems and functions in the test, agreed with the competent authority. Defining that scope means knowing which applications are critical, which support critical business functions, which carry cross-border or cross-entity dependencies, and which are run by ICT third parties. With an authoritative ICT landscape model, scope definition is a query. Without one, it becomes a manual, error-prone research exercise.

Building the DORA architecture in Sparx EA

ICT service landscape documentation

The foundation is the ICT service landscape: every application, cloud service, data center, and ICT third-party arrangement in scope for DORA. Each ICT asset is modeled as an ArchiMate Application Component (for software and cloud services) or a Technology Node (for infrastructure). A DORA MDG Technology profile adds a consistent set of tagged values to every in-scope asset:

Tagged value	What it captures
DORA Asset Classification	Asset type per the ESA taxonomy: Application Software, Cloud Service (IaaS / PaaS / SaaS), Communication Network, Hardware, Data, or Managed Service.
Provider	Name and LEI of the ICT third-party provider, where applicable; internal systems are marked as internally provided.
Third-Party Flag	Boolean that triggers the Register data-collection workflow for that asset.
Business Criticality	Critical (loss constitutes a major ICT incident), Important (affects operations without triggering major classification), or Standard.
RTO / RPO	Recovery Time and Recovery Point Objectives in hours — the business continuity and data-recovery documentation DORA's risk framework requires.
Resilience Tier	Tier 1 (active-active), Tier 2 (active-passive, near-instant failover), Tier 3 (warm standby within RTO), Tier 4 (cold standby, manual recovery).
TLPT Scope Flag	Boolean marking assets included in the TLPT scope agreed with the competent authority.
Data Residency	The country or countries where the service's data is stored — required for the Register.

Register of Information structure

The Register is modeled in Sparx EA as a structured package with three element types working together:

• ICT Arrangements — each contractual arrangement with a provider is a Requirement element carrying tagged values that map to the mandatory ESA Register fields, linked to the Application Components and Technology Nodes it covers.
• Provider Entities — each ICT third-party provider is an Actor element with LEI, country of incorporation, and group-parent tagged values, connected to the ICT Arrangements by association.
• Financial Entities — for groups with multiple regulated entities, each entity subject to DORA carries its LEI, entity type, and competent authority. Intra-group arrangements are modeled separately from third-party ones.

Because the Register fields live on the model, the Register itself becomes a query: walk the tagged values on ICT Arrangements, their linked assets, and their linked providers, and populate the ESA template — no parallel spreadsheet to keep in sync.

Business continuity: the failover topology

DORA's risk framework requires documented business continuity arrangements — backup systems, failover procedures, recovery architecture. In Sparx EA the failover topology lives in the ArchiMate technology architecture layer:

• Technology Nodes represent infrastructure components: primary data center, secondary data center, cloud availability zones, edge locations.
• Infrastructure Services represent hosting and connectivity (colocation, cloud IaaS, WAN connectivity).
• Assignment relationships connect Application Components to Technology Nodes, recording where each application runs.
• Redundancy relationships (ArchiMate Serving relationships with a «Failover» stereotype) connect primary to secondary nodes, annotated with failover trigger type, failover time, and last-tested date.

Application Components carrying RTO/RPO values, joined to a technology-layer failover topology, give you the DORA-required business continuity picture in one governed repository — connected across layers rather than scattered across documents.

Third-party risk register

Third-party risk management is implemented through a Requirements package of ICT risk assessments. Each critical arrangement carries a set of assessment elements:

• Concentration Risk Assessment — whether excessive dependence on one provider creates systemic risk.
• Substitutability Assessment — the time and cost to switch to an alternative provider if the current one fails or exits.
• Sub-outsourcing Chain Assessment — the provider's own significant sub-processors, the supply chain below the direct provider.
• Exit Strategy Assessment — the documented exit plan for each critical arrangement, including data portability and transition services.

These assessments link to their ICT Arrangement and Provider elements through trace relationships, completing the third-party risk picture inside the same model.

The DORA stereotype profile

The DORA MDG profile defines four stereotypes used across the architecture:

Stereotype	Applied to	Representative tagged values
«DORA-ICTAsset»	Application Components, Technology Nodes	AssetClassification, Provider, ThirdPartyFlag, BusinessCriticality, RTO_hours, RPO_hours, ResilienceTier, TLPTScopeFlag, DataResidency
«DORA-ICTArrangement»	Requirement elements (contracts)	ArrangementType, CriticalityClassification, SubstitutabilityRating, ContractStartDate, ContractEndDate, ExitStrategyDocRef
«DORA-Provider»	Actor elements (providers)	ProviderLEI, ProviderCountry, ProviderGroupParent, ProviderType
«DORA-Failover»	ArchiMate Serving relationships	FailoverType, FailoverTime_hours, LastTestedDate, TestResultRef

This profile is the MDG deliverable — an XML technology that, once loaded into Sparx EA, surfaces every DORA-required attribute through the standard stereotype picker and tagged-values panel, so the metadata is consistent across the whole estate rather than improvised model by model.

Keeping the Register live

DORA's ongoing-maintenance obligation is where a model earns its keep. A Register kept in a spreadsheet goes stale the moment a new cloud service is contracted or an arrangement expires. A Register generated from the EA repository is current by construction, because the repository is the system of record for the ICT landscape and is updated as a matter of normal architecture governance.

From that single source you can drive the outputs DORA and your supervisors expect:

• Compliance reporting — Register coverage (share of ICT assets with complete data), a third-party concentration heat map by provider, geography, and service type, resilience-tier distribution across the critical portfolio, RTO/RPO gap analysis, and TLPT scope completeness.
• Supervisory submissions — the ICT Arrangement elements, with their full tagged-value set, queried and shaped into the ESA-mandated template. When a competent authority requests the Register, the response comes from the live repository, not a months-old file.
• Renewal workflow — arrangements with contract end dates inside 90 days surface as a renewal action list, so the annual review obligation sits inside a workflow rather than a calendar reminder.

Frequently asked questions

Where Sparx Services fits

DORA compliance is not a one-time project; it is a standing architecture obligation. Sparx Services helps financial organizations build the practice that keeps it satisfied: the ICT service landscape with a full DORA MDG profile, the Register of Information structure, the resilience and failover topology, and the third-party risk register — all in a governed Sparx EA repository so the Register stays current as the ICT estate evolves. If you need to understand your current-state ICT documentation first, we can begin by inventorying the landscape before structuring it into the DORA architecture. See how we support enterprise architecture practices and architecture leaders.