Operationalizing DORA in Modulos

This page is the practical rollout playbook for DORA (Regulation (EU) 2022/2554) in Modulos. It assumes the organisation has already determined that DORA applies (see Applicability and governance) and walks through the OFF-16 and MFF-16 framework templates, the recommended project structure, the manual scoping pattern for conditional duties, the sequencing, and the evidence package supervisory authorities and auditors typically expect.

Quick decision

• Stand up the programme for the first time → start with one OFF-16 organisation project for governance and one MFF-16 ICT-system / AI-application project per material ICT system. Add the OFF-15 (NIS2) framework template too if you are also a NIS2 essential or important entity under national transposition.
• In Article 16 simplified-framework scope → Articles 5–15 are disapplied and the Article 16(1)(a)–(h) duties apply instead; Articles 17–19 incident reporting, the Article 28 lifecycle and register duties, and Article 45 information-sharing still apply (the Article 28(2) strategy duty and TLPT do not — both carve out Article 16(1) entities). Record the eligibility memo on ORF-362, then fulfil the Simplified-tagged limbs of the RMF requirements and record the Full-only limbs as out of scope.
• Already running an enterprise risk management framework → map Articles 6–16 onto the existing ERM; the DORA-specific substance is the Articles 17–19 reporting workflow + Articles 28–30 ICT third-party register + the testing programme + TLPT where applicable.
• Heavy ICT third-party dependency → the Articles 28–30 + register-of-information workflow is typically the longest stretch of the rollout. Start it in parallel with the RMF substance rather than sequentially.

TL;DR

• Modulos models DORA as two framework templates: OFF-16 (organisation, 29 requirements, 87 unique mapped controls) and MFF-16 (ICT system / AI application, 18 requirements, 54 unique mapped controls).
• Every requirement cites its precise legal basis — article and paragraph, plus the relevant RTS/ITS, with EUR-Lex links — in a References section, and states which entities each limb binds in an Applicability section.
• Scope is handled through the requirement-level Applicability sections plus three DORA tag families, not a questionnaire. ORF-361 and ORF-362 carry the Article 2 / 4 / 16 baseline; DORA Framework tags (Full / Simplified) and DORA Addressee tags mark which cohort each limb binds; DORA Pillar tags group requirements by operative area.
• The DORA rollout has seven natural stages: scope → governance → RMF substance → incidents → testing → ICT third-party → information sharing.
• Modulos surfaces relevant: project-dashboard Add Framework, Project → Requirements, Project → Controls, Project → Evidence, requirement readiness + owner-attested fulfilment, control review requests.
• Modulos does not provide a dedicated incident-reporting UI surface, a dedicated DORA register-of-information UI, a dedicated TLPT workflow surface, or a dedicated subcontracting-tracker UI — these are handled through requirements + evidence patterns.

Primary source

Regulation (EU) 2022/2554 on EUR-Lex · the eight Commission Delegated and Implementing Regulations (see Information sharing and Level 2 acts) · ESAs JC 2024-34 Joint Guideline

Project structure that works

Most financial-entity DORA rollouts use the following structure:

• One organisation project with the OFF-16 framework template attached. This holds Article 5 management-body governance, Articles 6–16 ICT RMF governance, Articles 17–23 incident-reporting governance, Articles 24–27 testing governance, Articles 28–30 ICT third-party governance, and the Article 45 information-sharing arrangement.
• One ICT-system / AI-application project per material system with the MFF-16 framework template attached. Each project holds the per-system execution evidence: RMF implementation, asset inventory entries, ICT-system-specific incident handling, system-level testing, TPP entries on the register, and subcontracting flow-down.
• Optional: a shared policy project for cross-system policies (ICT-RMF policy, incident-handling SOP, BC/DR plan, ICT-TPP policy, key contractual templates).

How to operationalize DORA in Modulos

The Modulos surfaces relevant to DORA rollout are:

Surface	Use
Project dashboard Add Framework	Attach OFF-16 to the organisation project; attach MFF-16 to each ICT-system / AI-application project
Project → Settings → Frameworks	Manage attached frameworks — list, freeze, and update
Project → Requirements	Track the OFF-16 / MFF-16 requirements; status Not fulfilled → Fulfilled (with optional Out of scope)
Requirement-level Applicability section	Label conditional duties (e.g. Article 16 simplified-framework eligibility, TLPT scope, Article 45 participation)
Requirement-level DORA Pillar, DORA Framework, DORA Addressee tags	Navigate by operative area; isolate the Full vs Simplified regime limbs; see at a glance which cohort each limb binds
Project → Controls	Document implemented measures (ICT-RMF policy, incident-handling runbook, testing programme, vendor due-diligence policy, register template, subcontracting checklist) and map them to one or more requirements; control status changes are routed through review requests
Project → Evidence	Store supporting artefacts (RMF document, resilience strategy, asset inventory, incident reports, testing outputs, vendor contracts, register entries, subcontracting assessments) and link them to controls
Comments and logs on each requirement	Capture the rationale for fulfilment attestation, scoping decisions, and corrective-action records

What ships with the templates

The OFF-16 / MFF-16 templates pair two kinds of controls. DORA-specific overlay controls carry the article-cited guidance for one duty — each overlay's guidance walks through criteria and thresholds, verification steps, results and gaps, evidence and storage, and refutation and updates, against the exact article and paragraph it implements, with full-regime and simplified-regime limbs kept separate. Shared framework-agnostic controls (leadership, competence, document review, management review, and similar governance substance) are the same control objects reused by the ISO 27001 / ISO 42001 / NIS2 templates, so evidence recorded once serves every attached framework. The shared controls deliberately carry no DORA-specific text — the DORA substance always sits on the overlay, which keeps cross-framework reuse clean.

DORA tag families reference

Three DORA tag families classify the OFF-16 / MFF-16 requirements and their controls.

DORA Pillar — the operative area:

Value	Covers
ICT Risk Management	Chapter II, Arts 5–16 — the ICT RMF and protection, detection, response, recovery, and learning duties
ICT Incident Management & Reporting	Chapter III, Arts 17–23 — incident management, classification, and reporting
Digital Operational Resilience Testing	Chapter IV, Arts 24–27 — the testing programme and TLPT
ICT Third-Party Risk	Chapter V Section I, Arts 28–30 — third-party risk management and key contractual provisions
Information & Intelligence Sharing	Chapter VI, Art 45 — voluntary cyber-threat information-sharing arrangements
Governance & Organisation	Art 5 — the management body's responsibility for the ICT RMF

DORA Framework — which regime a limb belongs to:

Value	What it marks
Full	The full ICT risk-management regime of Arts 5–15, applicable where the Art 16(1) simplified regime does not apply
Simplified	The Art 16(1) regime, which disapplies Arts 5–15 for the listed entities and substitutes the lighter points (a)–(h)

DORA Addressee — the cohort each limb binds. DORA's obligations are not uniform: many paragraphs carry their own addressee carve-out, and these tags make each limb's cohort explicit:

Value	What it marks
All financial entities	Paragraphs opening "Financial entities shall …" that bind the full and simplified regimes alike, including microenterprises (e.g. Arts 17–19, 28(3)–(8), 29, 30)
Other than microenterprises	Limbs carving out microenterprises (e.g. Art 6(4) control function, Art 11(6) second subparagraph and Art 11(7), Art 12(4), Art 24(1) testing programme)
Other than Art 16(1) entities and microenterprises	Double carve-outs (e.g. the Art 28(2) ICT third-party risk strategy; the Art 26(1) TLPT duty, which additionally requires Art 26(8) identification by the competent authority)
Microenterprises only	The inverse cohort — e.g. Art 25(3), under which microenterprises perform testing on a risk-based, proportionate basis
Simplified (Art 16(1) entities)	The simplified-regime cohort, used on every Simplified limb (the Art 16(1)(a)–(h) duties and their RTS 2024/1774 Title III detail)

Together with the per-requirement Applicability sections, the tags answer the two questions every DORA rollout starts with: which regime am I in (DORA Framework, after the ORF-362 eligibility memo) and which limbs bind me (DORA Addressee).

Sequence that works

A pragmatic seven-stage rollout sequence:

1. Scope and proportionality. Fulfil ORF-361 (Article 2(1) scope determination, including Article 2(3) exclusions) and ORF-362 (Article 4 proportionality + Article 16 simplified-framework eligibility memo).
2. Management body + RMF foundation. Fulfil ORF-363–ORF-366 and MRF-293. Article 5 management-body charter / terms of reference, the ICT risk management framework document, and the digital operational resilience strategy are the first evidence artefacts.
3. Resilience backbone (Articles 7–14). Fulfil ORF-367–ORF-375 (governance) and MRF-294–MRF-301 (execution). The ICT asset inventory under Article 8 is typically the longest piece of substance to assemble.
4. Incidents and reporting (Articles 17–23). Fulfil ORF-376–ORF-381 and MRF-302–MRF-304. Even before a real incident, run a simulated end-to-end Article 19(4) sequence (initial notification / intermediate report / final report) with timestamped artefacts and store as evidence — using the 2025/302 forms with 2025/301 content rules.
5. Testing and TLPT (Articles 24–27). Fulfil ORF-382–ORF-383 and MRF-305–MRF-306. ORF-382 splits into the three testing cohorts (full programme / microenterprise Article 25(3) / simplified Article 16(1)(g)) — fulfil the limb matching the entity's cohort. Where the entity is identified for TLPT under Article 26(8), the ORF-383 overlay controls stage the lifecycle in three phases: scoping and preparation, tester governance and execution, closure and remediation. The testing programme and (where applicable) the TLPT scope memo + tester assurance + remediation records are the central artefacts.
6. ICT third-party (Articles 28–30). Fulfil ORF-393 (Article 28(2) strategy, where the entity is outside the Article 16(1) and microenterprise carve-outs), ORF-384–ORF-387, and MRF-307–MRF-310. The Article 28(3) register of information (using the 2024/2956 template) and the Article 30 contractual baseline are the central artefacts; subcontracting assessment (Delegated Regulation 2025/532) attaches per relevant contract.
7. Article 45 information sharing. Where the entity participates, fulfil ORF-388.

Readiness + fulfilment attestation

Requirements in Modulos use a two-step pattern, not a review:

• when all linked controls are in a final state, the requirement becomes ready for review (a signal to the requirement owner);
• the requirement owner attests fulfilment by marking the requirement Fulfilled, with rationale captured in the requirement's comments and logs.

Review requests in Modulos apply to control status changes (and other reviewable objects like assets) — not to requirements themselves.

Evidence package baseline

A defensible DORA evidence package typically includes:

• Articles 1–4 + 16 scope — entity-category determination, Article 2(3) exclusion analysis where applicable, Article 4 proportionality memo, Article 16 simplified-framework eligibility memo.
• Article 5 management body — charter / terms of reference reflecting Article 5 responsibilities, approval minutes, training records, digital operational resilience strategy.
• Articles 6–14 RMF — ICT risk management framework document, ICT security policies, vulnerability-management programme, change-management policy, identity-and-access policy, ICT asset inventory + dependency map (Article 8), BC/DR plan with test outputs, crisis-communication plan, post-incident review template.
• Article 11(10) — aggregated annual cost / loss estimation reported to the competent authority upon request, using the methodology of ESAs Joint Guideline JC 2024-34 (mandated by Article 11(11)).
• Articles 17–23 incidents — incident-handling SOP, incident-classification methodology (per Delegated Regulation 2024/1772), executed Article 19(4) sequence (initial / intermediate / final using 2025/302 forms with 2025/301 content rules), authority feedback records.
• Articles 24–27 testing — testing programme document, annual testing plan + outputs, TLPT scope memo + tester qualification evidence + tester remediation records (per Delegated Regulation 2025/1190).
• Articles 28–30 ICT third-party — strategy on ICT third-party risk with the ICT TPP policy (Article 28(2), policy content per Delegated Regulation 2024/1773, where the entity is outside the Article 16(1) and microenterprise carve-outs), TPP due-diligence reviews, concentration-risk analysis, signed contracts with Article 30(2)–(3) provisions, register of information using the 2024/2956 standard template, subcontracting assessments (per Delegated Regulation 2025/532).
• Article 45 — information-sharing arrangement participation records and the Article 45(3) competent-authority notification of participation (and of any cessation of membership).

Cross-framework reuse with NIS2

Many financial entities are also NIS2 essential or important entities under national transposition. DORA Article 1(2) operates as a sector-specific Union legal act for the purposes of NIS2 Article 4: on matters DORA covers, DORA's specialised provisions apply; NIS2 obligations remain relevant where DORA does not cover the matter and where the national transposition extends further.

In Modulos, the standard pattern is to attach both OFF-15 (NIS2) and OFF-16 (DORA) to the same organisation project. Shared substance (ICT risk management policy, incident-handling SOP, BC/DR plan, vendor due-diligence policy, AI-BOM) is recorded once as evidence and linked to controls under both frameworks. See NIS2 vs DORA for the article-by-article mapping.

Related pages

DORA overview

Framework structure, key dates, OFF-16 / MFF-16 split

Applicability and governance

Articles 1–6, 16 — scope, proportionality, management body, ICT RMF foundation

ICT risk and resilience operations

Articles 5–23 — RMF substance, incident process, classification, reporting

Testing and third-party risk

Articles 24–30 — testing, TLPT, register of information, subcontracting

Information sharing and Level 2 acts

Article 45 + the eight Commission Delegated / Implementing Regulations

NIS2 vs DORA

Where each applies, sector-specific Union legal act interaction

Source attribution

Regulation (EU) 2022/2554 (DORA) is published in the Official Journal of the European Union L 333, 27.12.2022, pp. 1–79. This operationalize page describes how Modulos maps DORA obligations to platform surfaces; the binding obligations themselves are in the Regulation, the eight Commission Delegated and Implementing Regulations (2024/1772, 2024/1773, 2024/1774, 2024/2956, 2025/301, 2025/302, 2025/532, 2025/1190), and the ESAs Joint Guidelines.

Disclaimer

This page is for general informational purposes and does not constitute legal advice. The recommendations here describe common practice for DORA-aligned governance programmes. For binding interpretation in your jurisdiction, consult the published EUR-Lex text and qualified counsel.