DORA Compliance Architecture: Modeling Digital Operational Resilience in Sparx EA

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 and related to the contract, vendor and risk records that already exist, so the Register is generated from connected, current data 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.

What DORA actually asks for

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 that goes better when the contract and vendor details are read from the systems that hold them and the model relates them to the ICT landscape, instead of a hand-maintained spreadsheet.

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 attributes to every in-scope asset. Some are architectural decisions that the architect models. Others are facts that already sit in other systems and are connected to the model:

ICT service landscape documentation

Attribute	What it captures	Where it comes from
DORA Asset Classification	Asset type per the ESA taxonomy: Application Software, Cloud Service (IaaS / PaaS / SaaS), Communication Network, Hardware, Data, or Managed Service.	Modeled by the architect.
Provider	Name and LEI of the ICT third-party provider, where applicable; internal systems are marked as internally provided.	Connected from the contract and vendor records.
Third-Party Flag	Boolean marking assets that have an ICT third-party arrangement, so the Register includes them and gaps in the provider data are listed.	Derived from the connected contract records.
Business Criticality	Critical (loss constitutes a major ICT incident), Important (affects operations without triggering major classification), or Standard.	Modeled, using the criticality assessments held in the eGRC system.
RTO / RPO	Recovery Time and Recovery Point Objectives in hours, the business continuity and data-recovery documentation DORA's risk framework requires.	Connected from the business continuity records.
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).	Modeled by the architect, as a design fact.
TLPT Scope Flag	Boolean marking assets included in the TLPT scope agreed with the competent authority.	Modeled, as the decision agreed with the authority.
Data Residency	The country or countries where the service's data is stored, required for the Register.	Connected from the contract and cloud-service records.

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 the mandatory ESA Register fields, connected from the contract records and 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, connected from the vendor records and associated with its ICT Arrangements.
• 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 model relates the arrangements, the assets, and the providers, the Register becomes a query across them. The result populates the ESA template with no parallel spreadsheet to keep in sync. The contract owner keeps the contract record current in its source, and the Register follows.

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 and failover time; the last-tested date is read from the resilience test records.

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

The assessments behind third-party risk management are held in the eGRC system that runs it. AI connects to them, and the model relates each assessment to its arrangement and provider. Each critical arrangement carries a set of assessments:

• 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.

Because each assessment is related to its ICT Arrangement and Provider elements, the concentration, substitutability, sub-outsourcing, and exit picture sits next to the dependencies it concerns.

The DORA stereotype profile

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

The DORA stereotype profile

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 named and typed consistently across the whole estate rather than improvised model by model. Attributes that describe a contract, a provider’s legal identity, or a test result (such as ArrangementType, ContractStartDate, ContractEndDate, ProviderLEI, LastTestedDate) are connected from the contract, vendor, and test records, not entered by hand.

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 connected data follows its sources: the contract record, the vendor record, and the model’s view of what depends on them. The architecture changes through normal architecture governance, and the arrangements and providers update when their records do. Automation checks completeness, people own correctness: the architect decides which arrangements count as ICT third-party arrangements and reviews what AI connected before a submission.

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 connected Register fields, queried and shaped into the ESA-mandated template. When a competent authority requests the Register, the response comes from current data, not a months-old file.
• Renewal workflow, arrangements with contract end dates inside 90 days (read from the contract records) surface as a renewal action list, so the annual review obligation sits inside a workflow rather than a calendar reminder.

What your architects can now get done

The jobs below sit between the contract owners, the risk function and the supervisors. The tools help with each; the skill that decides the result is the architect’s.

Keeping the Register of Information current

Today the Register is a spreadsheet that someone updates from contracts and vendor lists, and it drifts from the first day after filing.

AI-augmented, the architect says which system is the source of record for each Register field and which arrangements count as ICT third-party arrangements, and AI connects to the contract, vendor and risk systems and relates their records to the assets and providers in the model.

The skill is stating the inclusion rules precisely, and reviewing what AI connected before a submission, because the filing belongs to the entity.

Tools that help: Claude + AI Power Tools, GitHub Copilot + AI Power Tools or Kernaro AI Hub.

Defining the TLPT scope

Today scope is researched by hand across inventories and interviews, and it is agreed with the authority on the strength of the last audit.

AI-augmented, the architect states what makes an asset critical for testing, and asks the model for every critical function, the systems behind it, and the third parties it depends on.

The skill is writing the scoping test precisely and noticing what the model has no way of knowing.

Tools that help: Kernaro AI Hub, Claude + AI Power Tools or GitHub Copilot + AI Power Tools.

Which tool helps depends on the job. Compare the AI options.

Frequently asked questions

Where Sparx Services fits

DORA compliance is a standing architecture obligation, not a one-time project. 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 picture, all in a Sparx EA repository connected to your contract, vendor and risk systems 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.

We teach your architects to work this way on your own repository: start at For Architects. Or we build and update the model for you, connected to your source systems: what we build. Either way, the compliance dashboards land in Prolaborate or Power BI: Reporting and Power BI. See also how we support enterprise architecture practices and architecture leaders.