DORA

This guide explains how Modulos operationalizes Regulation (EU) 2022/2554 through both organization-level and application-level framework objects.

Key facts

Type

EU regulation (financial sector)

Primary scope

Digital operational resilience for financial entities

Application date

17 January 2025

Core obligations

ICT risk, incident reporting, resilience testing, and ICT third-party risk

Modulos objects

OFF-16 (org) and MFF-16 (app)

Requirement model

28 org requirements and 18 app requirements

Applicability handling

Manual applicability notes on conditional requirements

Practical framing

In Modulos, DORA is split deliberately: OFF-16 carries entity governance and legal accountability, while MFF-16 carries service or application execution of the corresponding DORA duties.

How DORA is modeled in Modulos

Framework	Project type	Focus	Requirement count
OFF-16 (DORA (org))	Organization	Scope, proportionality, management-body duties, ICT risk governance, incident/reporting governance, testing, and ICT third-party governance	28 (ORF-361 to ORF-388)
MFF-16 (DORA (app))	AI application	ICT risk execution, incident evidence and reporting preparation, testing/TLPT execution, and ICT third-party execution	18 (MRF-293 to MRF-310)

Structure in practice

The current DORA model has five practical layers:

• Base org scope and governance in ORF-361 to ORF-366
• Org ICT risk and resilience governance in ORF-367 to ORF-375
• Org incident, reporting, and cohort-specific reporting duties in ORF-376 to ORF-381
• Org testing, third-party, subcontracting, and information-sharing duties in ORF-382 to ORF-388
• App-side execution in MRF-293 to MRF-310

This keeps DORA article families auditable without turning every Level 2 subsection into its own requirement.

Applicability model

Modulos does not currently use a dedicated DORA questionnaire or a static DORA Scope tag family to auto-descope requirements.

Instead:

• the main framework perimeter is handled through ORF-361 and ORF-362
• each genuinely conditional DORA requirement carries an explicit Applicability section
• the user or reviewer records why a conditional duty is in scope or out of scope

This is a deliberate design choice. It keeps the DORA model lean while still making conditional duties explicit and reviewable.

Coverage domains in this guide

• Applicability and governance: scope, proportionality, management-body duties, and the base ICT risk-governance model.
• ICT risk and resilience operations: the Article 7 to 23 risk, continuity, incident, and reporting families across org and app layers.
• Testing and third-party risk: Article 24 to 30 testing, TLPT, contract, register, and subcontracting duties.
• Information sharing and Level 2 acts: Article 45 plus the way Level 2 acts are threaded into the framework rather than modeled as a standalone watchlist requirement.
• Operationalizing in Modulos: a practical rollout sequence for OFF-16 and MFF-16.

Relationship with NIS2

NIS2 and DORA remain separate framework families in Modulos. Many financial entities need both, but DORA provides the lex-specialis financial-sector operating model while NIS2 remains a broader cybersecurity directive. Keeping both frameworks explicit preserves traceability and avoids hidden assumptions in audit work.

Explore DORA in depth

Applicability and governance

Scope determination, proportionality, management-body accountability, and the governance foundation

ICT risk and resilience operations

End-to-end ICT risk, continuity, incident, and reporting model

Testing and third-party risk

Resilience testing, TLPT, ICT third-party due diligence, contract, register, and subcontracting workflows

Information sharing and Level 2 acts

Article 45 information-sharing and how the Level 2 acts are threaded into the framework

Operationalizing in Modulos

A pragmatic rollout sequence for OFF-16 and MFF-16

Disclaimer

This page is for general informational purposes and does not constitute legal advice.