DORA Compliance for Software Architecture Teams: A Practical Guide

The Digital Operational Resilience Act (DORA) is the EU's most significant regulatory change for financial services technology since PSD2. It applies to banks, insurance companies, investment firms, crypto-asset providers, and — critically — their ICT third-party service providers.

If you build software for financial services in the EU, DORA affects you.

What DORA Requires (Articles 5-28)

DORA is structured around 5 pillars:

1. ICT Risk Management (Articles 5-16)

Every financial entity must maintain a documented ICT risk management framework. This includes:

• A complete inventory of all ICT assets and their dependencies
• Risk assessments for each critical function
• Business continuity plans with defined RTO and RPO
• Incident response procedures

Architecture implication: Your ArchiMate model IS your ICT asset inventory. Every ApplicationComponent, TechnologyService, and Node in your architecture model maps to an ICT asset that DORA requires you to document.

2. ICT Incident Reporting (Articles 17-23)

Financial entities must report major ICT incidents to regulators within strict timelines:

• Initial notification: within 4 hours of classification
• Intermediate report: within 72 hours
• Final report: within 1 month

Architecture implication: Your monitoring and alerting architecture must support incident classification and automated reporting. This means structured logging, severity classification, and integration with regulatory reporting APIs.

3. Digital Operational Resilience Testing (Articles 24-27)

Regular testing of ICT systems including:

• Vulnerability assessments (at least annually)
• Penetration testing (at least every 3 years for critical functions)
• Threat-Led Penetration Testing (TLPT) for systemically important entities

Architecture implication: Your architecture must define the scope of penetration tests. System boundaries, integration points, and data flows documented in ArchiMate provide the testing scope definition that Article 25 requires.

4. ICT Third-Party Risk (Articles 28-44)

Financial entities must:

• Maintain a register of all ICT third-party providers
• Assess concentration risk (too much dependency on one provider)
• Include specific contractual clauses (data location, audit rights, exit plans)

Architecture implication: Every TechnologyService and ExternalService in your ArchiMate model represents a third-party dependency. The architecture model can auto-generate your ICT third-party register.

5. Information Sharing (Articles 45)

Voluntary sharing of cyber threat intelligence between financial entities.

Building DORA-Compliant Architecture

At Archiet, we've mapped all DORA articles to ArchiMate elements. When you build your architecture blueprint, the DORA compliance report generates automatically:

Article 6 — ICT Risk Management Framework:

• Checks: Are all system boundaries documented? Are data flows mapped? Does the architecture cover identify, protect, detect, respond, recover?
• Evidence: Architecture diagram showing all components, relationships, and security boundaries

Article 8 — ICT Asset Inventory:

• Checks: Is every component assigned a criticality level? Is data classification applied?
• Evidence: Complete list of ApplicationComponents, TechnologyServices, and Nodes with their criticality and data classification

Article 18 — Business Continuity:

• Checks: Are RTO and RPO defined for each critical system? Are backup procedures documented?
• Evidence: Technology layer elements with availability requirements

Article 25 — Penetration Testing Scope:

• Checks: Are system boundaries formally derived from architecture?
• Evidence: Integration points, external interfaces, and attack surface derived from ArchiMate relationships

Article 28 — Third-Party ICT Register:

• Checks: Are all external service providers identified and classified?
• Evidence: ExternalService elements with provider details, data location, and contractual requirements

The 16-Point DORA Checklist

We've distilled DORA into 16 concrete checklist items that architecture teams can verify:

1. ICT risk management framework documented and reviewed within 12 months
2. System boundaries and data flows mapped in architecture
3. Architecture covers identify, protect, detect, respond, recover
4. All ICT assets supporting critical functions inventoried
5. Each asset assigned criticality: Critical / High / Medium / Low
6. Each asset assigned data classification: PII / Financial / PHI / Public
7. Business owner and IT security owner named for each critical asset
8. RTO defined and documented for every critical system
9. RPO defined and documented for every critical system
10. Backup and recovery procedures documented per system, tested annually
11. Incident response plan covers all in-scope systems with 72-hour notification
12. Third-party ICT provider dependencies included in incident response
13. Pen test scope formally derived from architecture
14. Vulnerability assessment conducted within last 12 months
15. All critical ICT third-party providers identified and classified
16. Contracts include data location, security standards, audit rights, exit plans

Archiet evaluates all 16 items automatically from your architecture blueprint and generates a scored DORA gap analysis.

Getting Started with DORA Compliance

1. Build your architecture — Use the Archiet wizard or import an existing ArchiMate model
2. Run the DORA assessment — Navigate to Compliance → DORA
3. Review gaps — Each unmet control comes with specific remediation guidance
4. Export the report — PDF format, ready for regulatory review

The 7-day free trial includes DORA assessment on the Professional plan. No credit card required.

DORA isn't optional. But it doesn't have to be painful.