First timers with DORA usually treat it as an IT project, build an incomplete register of ICT third parties, leave contracts without the required terms, discover the incident reporting clock too late, and equate resilience testing with one annual penetration test. The regulation text points to each of these.
1. Treating it as an IT project
Article 5 gives the management body ultimate responsibility for ICT risk. It must define, approve, oversee and answer for the framework, approve and periodically review continuity and response plans and the policy on third party ICT services, and keep its own knowledge current through training (Article 5(4)). If board minutes show no discussion of ICT risk, you have a gap that no tooling can fix. Put ICT risk on the board agenda, with training records.
2. Reviewing the framework once
Article 6(5) requires the ICT risk management framework to be documented and reviewed at least once a year, and after major incidents or supervisory findings. Entities other than microenterprises must also subject it to regular internal audit under Article 6(6). A framework approved at launch and never touched is an easy finding.
3. An incomplete register of information
Article 28(3) requires a register of all contractual arrangements for ICT services from third party providers, at entity and consolidated levels, distinguishing arrangements that support critical or important functions. First timers list only the big cloud contracts. Include software as a service tools, managed services, data feeds and intra group arrangements, and map each to the function it supports. Reconcile the register against accounts payable to find forgotten suppliers.
4. Contracts without the required terms
Article 30 requires written contracts with minimum content: service descriptions, data locations and termination rights, and for critical or important functions precise performance targets, audit and access rights, participation in threat led testing, and exit strategies with a mandatory transition period. Review contracts against the list and plan amendments. Providers often accept standard addenda, so start early.
5. Meeting the incident clock too late
Article 19(4) requires an initial notification, intermediate reports and a final report. The time limits are in a delegated regulation (EU) 2025/301, Article 5: the initial notification as early as possible and within four hours of classifying the incident as major, with an outer limit of 24 hours from awareness; an intermediate report within 72 hours of the initial notification; and a final report within one month of the latest intermediate report. Classification criteria come from Article 18, such as clients affected, duration, geographic spread, data losses, service criticality and economic impact. Build a classification worksheet and rehearse it.
6. Shallow resilience testing
Article 24(6) expects appropriate tests on all ICT systems and applications supporting critical or important functions at least yearly. Article 25 lists test types, including vulnerability assessments, open source analyses, gap analyses, scenario based tests and penetration testing. Entities identified for advanced testing must perform threat led penetration testing at least every three years under Article 26, on live production systems, with external testers every three tests if internal testers are used. A single penetration test does not cover this.
7. Weak asset inventories
Article 8 requires you to identify, classify and document ICT supported functions, assets and dependencies, with reviews at least yearly and updates after major changes. Spreadsheets maintained by hand go stale. Tie the inventory to change management.
8. Ignoring exit plans
Critical functions need an exit strategy and transition period in the contract. Write the plan, name an alternative where possible and test the steps on paper.
9. Assuming proportionality is a free pass
Microenterprises have lighter duties, but the framework still applies. Record your basis for proportionality and have it ready for the supervisor.
What to do
- Put ICT risk on the board agenda and schedule training.
- Calendar the annual framework review and internal audit.
- Build the register with every arrangement and reconcile with payables.
- Review contracts against Article 30 and send amendments.
- Build an incident classification worksheet and test the four hour, 24 hour, 72 hour and one month steps.
- Plan yearly tests and, if you are identified, threat led testing.
- Link the asset inventory to change management.
- Write exit plans for critical providers.
Quick check
What is the incident reporting timeline?
Under delegated regulation 2025/301, Article 5: initial notification within four hours of classification and no later than 24 hours from awareness, an intermediate report within 72 hours of that, and a final report within a month of the latest intermediate report.
How often must the ICT risk framework be reviewed?
At least once a year under Article 6(5), and after major incidents or supervisory findings.
How Safeguard helps automate this
Inventories, registers and test evidence are where early programs fall behind. Safeguard's compliance suite covers frameworks, controls, evidence, continuous monitoring, automated tests and questionnaires, so evidence is collected from connected systems and code instead of by screenshot, and monitoring runs between reviews, which saves your team time for other work. Technical evidence comes from your real code and dependencies through scans, SBOMs and reachability, supporting the vulnerability and asset sections. The agent can open tested fix pull requests, but it is off by default, every category starts on Manual, and you choose which categories run automatically. Safeguard helps prepare evidence; your supervisor and auditors judge compliance. Book a call.
Sources
Last reviewed: 18 October 2026.
