DORA step by step for financial entities in the Benelux

A practical DORA path for banks, insurers, payment institutions and asset managers in Belgium, the Netherlands and Luxembourg, from ICT risk governance to major incident reporting.

This guide is for CISOs, CROs, compliance officers and heads of IT at banks, insurers, payment and e-money institutions, investment firms, asset managers and other financial entities in Belgium, the Netherlands and Luxembourg. Use it for a first gap assessment or to tidy up a framework built in a hurry before January 2025. The focus is on ICT risk management and incident handling. Testing, third-party risk and information sharing are covered more briefly.

Before you start

DORA puts ultimate responsibility for ICT risk on the management body (Article 5)^[1]. Before you start, make sure that a board member sponsors the work, that the ICT risk control function is independent from ICT operations, and that you know which supervisor is competent for each licensed entity in your group. Collect your existing ISMS documentation, business impact analysis, incident procedure and outsourcing register, because most DORA evidence builds on them. Proportionality (Article 4) applies throughout: size, risk profile and the nature, scale and complexity of your services determine how far you go.

Step 1: Confirm scope and the applicable framework

Start by determining which entities in the group are in scope and whether any of them qualify for the simplified ICT risk management framework of Article 16. That regime covers, among others, small and non-interconnected investment firms, payment and e-money institutions that are exempted under PSD2 or the E-Money Directive, and small IORPs. Those entities follow Title III of Delegated Regulation 2024/1774 (Articles 28–41), while all others follow Title II (Articles 2–27)^[2].

• List each entity, its licence, its competent authority and whether Article 16 applies.
• Check whether any entity is also an essential or important entity under NIS2. In general DORA works as lex specialis, but national reporting arrangements can differ.
• Agree how group-level policies will be adopted by each entity’s management body.

Step 2: Set governance and the ICT risk management framework

Article 5 requires the management body to define, approve, oversee and be accountable for the ICT risk management framework. It also requires board members to keep their ICT risk knowledge up to date through regular training. Article 6 requires a sound, comprehensive and documented framework, a digital operational resilience strategy, an independent control function, internal audit, and a review at least once a year and after major ICT-related incidents. Entities under the simplified regime review their framework periodically and report on that review as described in Article 41 of the RTS.

• Have the management body approve the framework, the digital operational resilience strategy and the ICT risk tolerance.
• Assign the ICT risk control function under the three lines of defence model, or an equivalent model, and document its independence.
• Plan board training on ICT risk and record attendance.
• Schedule the yearly framework review and the review report required by Article 27 of the RTS.

Step 3: Identify and classify ICT assets and functions

Article 8 requires you to identify and document your business functions, roles, information assets and ICT assets, and the dependencies between them. You must identify which functions are critical or important, map the ICT assets that support them, and assess ICT risk whenever there is a major change. Legacy systems and assets managed by third parties are explicitly included.

• Build or update the inventory of information and ICT assets, linking each to the business functions it supports.
• Classify assets by criticality and record the configuration of critical assets.
• Identify all ICT third-party dependencies, especially those that support critical or important functions.
• Perform a risk assessment on legacy ICT systems at least once a year.

Step 4: Implement protection and detection controls

Article 9 covers protection and prevention, and Article 10 detection. Title II, Chapters 1 and 2 of the RTS (Articles 2–21) set out the detail: ICT security policies, asset management, encryption and cryptographic key management, ICT operations security, network security, project and change management, physical security, human resources policies, and identity and access management. Article 23 of the RTS sets out what anomalous activity detection must cover.

• Map each RTS article to an existing policy or control, and record the gaps.
• Check that your patch management, vulnerability scanning, logging and change management procedures meet the specific RTS requirements.
• Define detection thresholds and alerting criteria, and make sure there are enough resources for monitoring.

The companion template includes a gap assessment that maps DORA Articles 5 to 45 and the main RTS articles to owners, status and evidence.

Step 5: Prepare response, recovery and backups

Articles 11 and 12 require an ICT business continuity policy, response and recovery plans, a business impact analysis, and backup and restoration procedures, with recovery objectives for each function. Business continuity plans must be tested regularly, and plans for critical or important functions at least once a year. Articles 24–26 of the RTS add the detail on continuity policy, testing and response and recovery plans.

• Update the business impact analysis and set recovery time and recovery point objectives for critical or important functions.
• Make sure backups are physically and logically segregated from the source systems, and test restoration.
• Run at least one scenario-based continuity test per year, including a severe cyber scenario.
• Prepare crisis communication plans for clients, staff, counterparts and the public (Article 14).

Step 6: Build incident management, classification and reporting

Article 17 requires an ICT-related incident management process, Article 18 classification, and Article 19 reporting of major incidents to the competent authority. Delegated Regulation 2024/1772 sets the classification criteria and thresholds. Delegated Regulation 2025/301 sets the content and time limits, and Implementing Regulation 2025/302 the templates^[3].

Report	Time limit
Initial notification	Within 4 hours of classifying the incident as major, and no later than 24 hours after becoming aware of it
Intermediate report	Within 72 hours of the initial notification, with updates when the status changes significantly
Final report	No later than one month after the latest intermediate report

For some entities, a deadline that falls on a weekend or a public holiday may move to noon on the next working day. This does not apply to initial and intermediate reports from credit institutions, central counterparties, trading venue operators and entities that are essential or important under NIS2.

• Embed the classification criteria (clients affected, duration, geographical spread, data losses, criticality of services, economic impact) in your incident tooling.
• Define who classifies an incident as major and who signs off on reports.
• Set up access to the supervisor’s reporting channel for named staff and deputies, and rehearse a submission.
• Decide how you will handle voluntary notification of significant cyber threats and communication to affected clients.

For a side-by-side view of DORA, NIS2, CRA and GDPR reporting, see our incident reporting playbook.

Step 7: Test digital operational resilience

Articles 24 and 25 require a risk-based testing programme, with appropriate tests of ICT systems and applications that support critical or important functions at least once a year. Tests range from vulnerability assessments and scans to scenario-based tests and penetration tests. Article 26 adds threat-led penetration testing (TLPT) at least every three years for entities identified by the competent authority. In practice this follows the TIBER-EU framework and its national versions.

• Draw up a multi-year testing plan linked to the asset criticality from Step 3.
• Track findings through to remediation, and report the results to the management body.

Step 8: Manage ICT third-party risk and keep the register current

Articles 28–30 require a strategy on ICT third-party risk, due diligence, mandatory contractual provisions and exit strategies. Article 28(3) requires a register of information on all contractual arrangements with ICT third-party service providers, in the format set out in Implementing Regulation 2024/2956. The register must be provided to the competent authority on request and is collected yearly. For a deeper treatment, see our article on third-party risk management in 2026.

• Reconcile the register with procurement and contract data at least quarterly.
• Check contracts for critical or important functions against Article 30 and plan renegotiation where needed.

Step 9: Learn, share and report back to the board

Article 13 requires post-incident reviews, the use of lessons learned, and ICT security awareness and training for all staff. Article 45 allows financial entities to exchange cyber threat information and intelligence within trusted communities, and entities that join must notify their competent authority. In Secrato, these recurring activities map to control tests in the Compliance Engine, so one result serves DORA, NIS2 and ISO 27001 at the same time.

• Run a post-incident review for every major incident and feed the findings into the framework review.
• Consider joining a sector information-sharing arrangement, and notify your supervisor if you do.
• Report status, test results and incident trends to the management body at least once a year.

How this connects to other frameworks

A well-run ISO 27001 ISMS covers a large part of the DORA ICT risk management chapter, and NIS2 Article 21 measures map closely to Articles 8–14. DORA goes further on board accountability, business continuity testing, incident classification thresholds, TLPT and contractual provisions with ICT providers. Map each DORA article to the controls you already test for ISO 27001 to avoid duplicate work.

Frequently asked questions

Can a payment institution use the simplified framework?

Only if it is exempted under PSD2. Authorised payment institutions apply the full framework, proportionately.

Is DORA incident reporting the same as NIS2 reporting?

No. DORA has its own classification criteria, templates and time limits. Where a financial entity also falls under national NIS2 rules, check with your supervisor whether a separate NIS2 notification is needed.

How often must the register of information be submitted?

Supervisors collect it yearly and can request it at any time. Check your supervisor’s collection calendar and format requirements.

Are we required to do TLPT?

Only if your competent authority identifies you for it. All entities need a testing programme with yearly tests of systems supporting critical or important functions.