A 12 week DORA calendar can run scoping and gap analysis in weeks one to three, ICT risk framework and asset work in four to six, incident and testing processes in seven to nine, and third party register, contracts and management reporting in ten to twelve. Treat it as a template to adapt, since no source sets a standard duration.
Who needs this calendar?
DORA, Regulation (EU) 2022/2554, applies from 17 January 2025 to financial entities and to ICT third party service providers, per the text and EIOPA. If you are a financial entity, the duties are yours directly. If you sell software or cloud services to financial entities, expect their contracts and questionnaires to carry DORA requirements. The calendar below speaks to a financial entity and notes the provider angle where useful. Proportionality applies: microenterprises and some others have simplified rules.
Weeks 1 to 3: scope and gap analysis
Confirm which entity type you are and which competent authority supervises you. List critical or important functions, and the ICT systems and providers behind them. Compare current practice against the regulation's areas: ICT risk management, incident management and reporting, digital operational resilience testing, ICT third party risk, and information sharing. Record gaps with owners. Owner: compliance lead and head of ICT.
Weeks 4 to 6: framework and assets
Document the ICT risk management framework, with management body approval. The text requires it to be documented and reviewed at least once a year. Identify and classify ICT supported business functions, information assets and ICT assets, and map dependencies (Article 8). Run the first assessment of legacy ICT systems. Owner: ICT risk lead.
Weeks 7 to 9: incidents and testing
Define how incidents are detected, classified and escalated. The regulation requires reporting of major ICT related incidents through an initial notification, an intermediate report and a final report on standard templates. I did not fetch the technical standards that set timings, so take them from the current standards and your authority. Write the playbook, then run a drill. Next, build the testing programme: yearly tests of systems supporting critical or important functions, and check whether you fall in the group that needs threat led penetration testing at least every three years. Owner: security operations.
Weeks 10 to 12: third parties and reporting
Build the register of information on all contractual arrangements for ICT services (Article 28(3)). List every provider, the service, the function supported and the contract. Review contracts for required terms and exit strategies for critical services. Prepare the first management report on findings and decisions. Owner: procurement with legal.
What evidence should exist at week 12?
An approved framework with a review date, an asset and dependency map, a legacy system assessment, an incident playbook and drill record, a test plan, the register of information, contract review results, and a dated management report. Each should name an owner.
What usually slips?
The register, because contracts sit in many hands. Start collecting contract data in week one, not week ten. Another slip is classifying critical functions without business input. Schedule that conversation early.
What to do
- Confirm entity type, authority and critical functions.
- Run the gap analysis against the regulation's areas.
- Get management approval of the framework.
- Build the asset map and legacy assessment.
- Draft the incident playbook and rehearse it.
- Plan yearly tests and check the three year testing rule.
- Build the register and review contracts.
- Deliver the first management report.
Quick check
Does DORA apply to software vendors?
It applies to financial entities and to ICT third party service providers. Vendors face direct duties only if designated as critical providers, and otherwise meet requirements through customer contracts.
Is the register of information optional?
No. The regulation requires financial entities to maintain it and make it available to the competent authority on request.
How Safeguard helps automate this
Weeks four to twelve produce a lot of artefacts that go stale. 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 continues after the plan ends, which gives the team time for other work. Technical evidence comes from your real code and dependencies, using scans, SBOMs and reachability, which supports the asset map and the third party software questions. 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. The authority and any assessor make the compliance judgement.
Try the framework mapping demo full screen.
Sources
Last reviewed: 18 October 2026.
