DORA expects a documented ICT risk management framework, a digital operational resilience strategy, an information security policy, ICT business continuity and recovery plans, backup procedures, an incident management process, a testing programme, a third-party risk strategy and a register of information. Your management body must approve key items and review them periodically.
Who does this apply to?
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) entered into force on 16 January 2023 and has applied since 17 January 2025, according to ESMA. Article 2 lists the financial entities in scope, among them credit institutions, payment institutions, investment firms, crypto-asset service providers and insurers. Check Article 2 for your own entity type, and check whether you qualify as a microenterprise, since several articles treat them differently. If you are an ICT provider to a financial entity, DORA reaches you mainly through contract terms and, for designated critical providers, direct oversight.
The documents, grouped by what they prove
Governance (Article 5). The management body defines, approves and oversees the framework and is responsible for it. Expect minutes showing approval of the digital operational resilience strategy, the risk tolerance level, the continuity policy, audit plans, budget for training and the policy on third-party ICT services. Written roles and responsibilities for ICT functions belong here too.
Framework and strategy (Article 6). A sound, comprehensive and well documented ICT risk management framework, reviewed at least once a year and after major incidents. Entities other than microenterprises assign oversight to a control function with appropriate independence and subject the framework to regular internal audit. The strategy under Article 6(8) sets out how you will reach resilience and what tolerance you accept.
Identification (Article 8). A classified inventory of ICT supported business functions, information assets and ICT assets, with dependencies, reviewed as needed and at least yearly. Yearly review of risk scenarios as well.
Protection and detection (Articles 9 and 10). An information security policy covering availability, authenticity, integrity and confidentiality, plus supporting standards for network management, access and change. Detection mechanisms that you test regularly.
Continuity and recovery (Articles 11 and 12). An ICT business continuity policy, response and recovery plans, backup policies that state scope and minimum frequency, and restoration procedures that you test periodically. Backup restores should use systems that are separated from the source environment.
Communication and learning (Articles 13 and 14). Communication policies for staff and external stakeholders, a named person responsible, and post incident review records. Staff awareness and resilience training programmes feed in here.
Incidents (Articles 17 to 19). A process to detect, manage and notify ICT incidents, a log of all incidents and significant cyber threats, classification criteria, and procedures to report major incidents to the competent authority. The detailed time limits and templates come from technical standards under Article 20, which this guide did not review. Get the current texts from the European Supervisory Authorities.
Testing (Articles 24 to 26). A documented testing programme proportionate to your size and risk, including vulnerability assessments and scans, source code reviews where feasible, scenario tests and penetration tests. Entities designated for advanced testing must run threat led penetration testing at least every three years.
Third parties (Articles 28 to 30). A strategy and policy on ICT third-party risk, a register of information on all contractual arrangements that separates critical or important functions from the rest, pre-contract due diligence records, and contracts containing the key provisions listed in Article 30, such as service descriptions, data locations and subcontracting conditions. Plan exit strategies for critical services.
What to do
- Confirm your entity type under Article 2 and note simplified regimes that may apply.
- Build a document register keyed by article, with owner, approver, version and next review date.
- Draft the framework, strategy and information security policy first. Everything else hangs off them.
- Take management body approval in minutes, not by email chain.
- Create the information asset inventory and the register of information in structured form, since regulators can ask for them.
- Write incident, continuity and testing procedures, then run each once and keep the record.
- Review all documents yearly and after major incidents, and log the review.
Quick check
Do I need a separate document for every article?
No. DORA allows some policies to be dedicated documents or parts of a broader policy, for example the ICT continuity policy can sit inside the overall business continuity policy. What matters is that each required element exists and is approved.
Is the register of information a spreadsheet job?
It can start as one, but you must keep it current at entity level and report on it to your authority. Structured data makes that easier.
How Safeguard helps automate this
A document register is only as good as the evidence behind it. 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. For testing and vulnerability duties, technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. Autonomous remediation can open tested fix pull requests for vulnerable dependencies and other findings; it is off by default, every category starts on Manual, and you decide which categories run automatically and at what approval level. Safeguard does not make you compliant or replace your supervisors or auditors. It helps you prepare and keep evidence ready. Book a call.
Sources
Last reviewed: 18 October 2026.
