You can implement DORA yourself by working in nine steps: confirm scope, set governance, inventory assets, write the ICT risk framework, build incident handling, plan continuity and backups, run a testing programme, bring third parties under contract, and set a review cycle. Treat it as a programme with owners and dated evidence, not a document sprint.
Step 1: Confirm scope and proportionality
Read Article 2 of Regulation (EU) 2022/2554 and find your entity type. Then check the proportionality language: the rules scale with size, risk and complexity, and microenterprises get simplified treatment in places. Write one page stating why DORA applies to you and which simplified rules, if any, you rely on. ESMA says the regulation has applied since 17 January 2025, so a plan should assume you are already in scope.
Step 2: Put the management body in charge
Article 5 makes the management body responsible for defining, approving and overseeing the ICT risk framework. Brief the board, schedule approvals, and record decisions: risk tolerance, strategy, continuity policy, audit plan, training budget, third-party policy. Entities other than microenterprises also need a control function with appropriate independence from those running ICT.
Step 3: Identify what you run
Article 8 requires you to identify, classify and document ICT supported business functions, the information and ICT assets behind them, and their dependencies. Start with business functions, mark which are critical or important, then trace down to systems and suppliers. Review at least yearly.
Step 4: Write the ICT risk management framework
Article 6 asks for a documented framework with strategies, policies, procedures, protocols and tools, reviewed at least yearly and after major incidents. Add the information security policy (Article 9), detection mechanisms (Article 10) and a plan for learning from incidents and tests (Article 13). Keep the first version short and true to current practice.
Step 5: Build incident handling
Define a process to detect, manage and notify ICT incidents (Article 17), classification criteria (Article 18) and a path to report major incidents to your competent authority (Article 19). Reporting time limits and templates come from technical standards, which we did not review here, so fetch the current versions from the European Supervisory Authorities. Rehearse once with a tabletop exercise and keep notes.
Step 6: Plan continuity, backup and recovery
Article 11 requires an ICT business continuity policy and response and recovery plans. Article 12 requires backup policies stating scope and minimum frequency, plus restoration procedures that you test periodically. Test plans should include cyber-attack scenarios and switchovers to redundant capacity, and the continuity and response and recovery plans are tested at least yearly (Article 11).
Step 7: Stand up a testing programme
Articles 24 and 25 call for a documented programme with a range of tests: vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, source code reviews where feasible, scenario tests and penetration tests. Some entities will be identified for threat led penetration testing at least every three years under Article 26. Record the scope, results and fixes for each test.
Step 8: Bring third parties into the framework
Article 28 treats ICT third-party risk as part of ICT risk. You stay fully responsible for compliance even when a provider runs the service. Build a register of information on all ICT service contracts, split into those that support critical or important functions and the rest. Check contracts against Article 30: service descriptions, data locations, subcontracting conditions and more. Agree exit strategies for critical services.
Step 9: Make it a cycle
Calendar the yearly reviews, test dates and register updates. Feed lessons from incidents and tests back into the framework, as Article 13 expects.
What to do this month
- Assign an executive owner and a day to day programme lead.
- Complete the scope page and get it approved.
- Start the asset and function inventory.
- Draft the framework outline with an owner for each chapter.
- List all ICT suppliers and mark the critical ones.
- Pick the first test or tabletop exercise date.
Quick check
How long will this take?
We did not find an official duration, so we do not give one. It depends on your size, how mature your ICT controls already are and how many suppliers you have.
Do I need an outside consultant?
DORA does not require one. Your supervisor expects the management body to own the framework, which is hard to outsource.
How Safeguard helps automate this
Steps 3, 7 and 8 produce the most recurring evidence. 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 the team time for other work. Technical evidence for testing and vulnerability management comes from your real code and dependencies: scans, SBOMs and reachability. Autonomous remediation 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. Safeguard does not certify you or replace your auditors or supervisor.
Open the framework mapping demo or book a call.
Sources
Last reviewed: 18 October 2026.
