DORA has applied since 17 January 2025, and it is built around repeating duties. After the first implementation, keep a calendar for the yearly ICT risk framework review, yearly resilience tests, yearly legacy system risk assessment, a live register of third party ICT arrangements, and incident reporting readiness. Each needs dated evidence.
What repeats, and how often?
EIOPA describes DORA as a regulation to strengthen the digital resilience of financial entities, applying to 20 types of financial entity and to ICT third party service providers. The regulation text sets several rhythms.
The ICT risk management framework must be documented and reviewed at least once a year, and also after major ICT related incidents and after supervisory instructions or findings (Article 6(5)). Microenterprises may review periodically instead.
Entities other than microenterprises must assess legacy ICT systems at least yearly, and before and after connecting new technologies (Article 8(7)).
Appropriate tests must be run at least yearly on all ICT systems and applications that support critical or important functions (Article 24(6)).
Entities identified for advanced testing must run threat led penetration testing at least every three years, though the authority may raise or lower that (Article 26(1)).
The register of information on contractual arrangements with ICT third party providers must be kept up to date, made available on request, and the entity must report yearly to authorities on new arrangements and categories of provider (Article 28(3)).
Senior ICT staff must report to the management body at least yearly on the findings of the resilience work. Check your own ICT staff reporting against the article text.
How do you monitor between those dates?
A yearly review that starts from a blank page will fail. Feed it from monthly and quarterly signals.
Monthly: new or changed ICT providers added to the register, changes to critical or important functions, open vulnerabilities by age, and incident and near miss logs. Quarterly: access reviews on critical systems, backup and recovery tests on rotation, exceptions and risk acceptances reviewed, and a check that contracts with providers still carry the required terms.
Incident reporting needs special care. The regulation requires an initial notification, an intermediate report and a final report for major ICT related incidents, using standard templates. Exact timings are set in technical standards that I did not fetch, so take the deadlines from the current regulatory standards and your supervisor. Rehearse them at least once a year.
What does a good monthly check look like?
Keep it to one page and one hour. Pull the list of providers added or changed since last month and confirm each has a register entry and a contract review. Pull open vulnerabilities on systems that support critical or important functions and sort by age. Read the incident and near miss log for patterns, for example repeated failures at one provider. Confirm that any change to a critical function has a matching update in the asset map and, where needed, a new risk assessment.
Record the outcome in a short note with a date and the name of the person who ran it. Twelve monthly notes are far better evidence of continuous oversight than one long annual report, and they make the yearly management report quick to write.
Treat exceptions the same way. If a system cannot be patched or a provider cannot meet a contract term, log the reason, the compensating measure, the approver and a review date. Review the log at each quarterly check.
Who owns what?
Management owns the framework and receives the reports. A named ICT risk lead owns the calendar. Procurement or vendor management owns the register of information. Engineering owns testing, patching and recovery evidence. Compliance owns the incident reporting templates and drills.
What evidence do you keep?
Dated framework versions with review minutes, test plans and results with remediation tickets, the register export with change history, provider due diligence files, incident logs and drill records, management reports, and decisions on accepted risks.
What to do
- Create a DORA calendar with every yearly and three yearly duty and an owner.
- Feed it with monthly and quarterly signals, not annual scrambles.
- Keep the register of information as a living file with change history.
- Run an incident reporting drill with the current templates and timings.
- Test critical functions yearly and track fixes to closure.
- Report findings to the management body and record decisions.
- Re-read the regulation and its technical standards each year for changes.
Quick check
How often must the ICT risk framework be reviewed?
At least once a year, and after major ICT related incidents and supervisory findings. Microenterprises review periodically.
Is threat led penetration testing yearly?
No. For entities identified for it, at least every three years, subject to the authority adjusting the frequency.
How Safeguard helps automate this
Recurring duties fail when evidence is gathered only once a year. 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 continuously between reviews. For the third party questions, technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability, which shows the software supply chain behind the register. Safeguard's agent can open tested fix pull requests for vulnerable dependencies. It is off by default, every category starts on Manual, and you choose which categories run automatically and at what approval level. Supervisors and independent assessors remain responsible for judging your compliance. Book a call to see it.
Sources
Last reviewed: 18 October 2026.
