Skip to content

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 → the simplified RMF applies but Articles 17–19 incident reporting, Articles 28–30 ICT third-party, and Article 45 information-sharing still apply. Note the proportionality framing in ORF-362 and select the simplified Article 6 framework on ORF-365.
  • 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, 28 requirements) and MFF-16 (ICT system / AI application, 18 requirements).
  • Scope is handled through requirement-level Applicability sections rather than a questionnaire. ORF-361 and ORF-362 carry the Article 2 / 4 / 16 baseline.
  • 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:

SurfaceUse
Project dashboard Add FrameworkAttach OFF-16 to the organisation project; attach MFF-16 to each ICT-system / AI-application project
Project → Settings → FrameworksManage attached frameworks — list, freeze, and update
Project → RequirementsTrack the OFF-16 / MFF-16 requirements; status Not fulfilledFulfilled (with optional Out of scope)
Requirement-level Applicability sectionLabel conditional duties (e.g. Article 16 simplified-framework eligibility, TLPT scope, Article 45 participation)
Project → ControlsDocument 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 → EvidenceStore 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 requirementCapture the rationale for fulfilment attestation, scoping decisions, and corrective-action records

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-363ORF-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-367ORF-375 (governance) and MRF-294MRF-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-376ORF-381 and MRF-302MRF-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-382ORF-383 and MRF-305MRF-306. The Article 25 testing programme and (where applicable) the Article 26 TLPT scope memo + tester assurance + remediation records are the central artefacts.
  6. ICT third-party (Articles 28–30). Fulfil ORF-384ORF-387 and MRF-307MRF-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 methodology (per ESAs JC 2024-34) and reports under 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 — ICT TPP policy (per Delegated Regulation 2024/1773), 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(2) competent-authority notification.

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.

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.