For DORA, Regulation (EU) 2022/2554, keep documents showing an ICT risk management framework, a classified asset inventory reviewed yearly, an incident process with records, a resilience testing programme, and a register of information on ICT third party contracts. The regulation applies from 17 January 2025, with proportionality for smaller entities.
What does DORA require in plain terms?
DORA sets uniform ICT risk rules for EU financial entities. Article 4 applies proportionality: rules scale with size, overall risk profile, and the nature, scale and complexity of services. Microenterprises get lighter duties in several articles. The evidence below follows the text of the articles we fetched from EUR-Lex. Regulatory technical standards and supervisory expectations add detail, so confirm them with your competent authority.
Which documents prove the ICT risk management framework?
Article 6(1) requires a sound, comprehensive and well documented ICT risk management framework, and Article 6(2) lists strategies, policies, procedures, protocols and tools protecting all information and ICT assets. Article 6(4) requires responsibility for managing and overseeing ICT risk to sit with a control function with appropriate independence (microenterprises excepted).
Evidence: the framework document, management body approval, the assignment of the control function, and the review records. Articles 6(3) also say you must provide complete and updated information on your framework to competent authorities on request, so keep it current and findable.
How do you prove asset identification?
Article 8(1) requires you to identify, classify and document ICT supported business functions, roles and responsibilities, and the information and ICT assets supporting them, with a review of the classification at least yearly. Article 8(2) requires continuous identification of ICT risk sources and a yearly review of risk scenarios. Article 8(3) requires a risk assessment on each major change for entities other than microenterprises. Article 8(4) asks for mapping of critical assets, their configuration and interdependencies.
Evidence: the asset inventory with criticality, dependency maps, the yearly review sign off, change risk assessments.
What counts as incident evidence?
Article 17 requires a defined incident management process to detect, manage and notify incidents, recording all ICT related incidents and significant cyber threats, with root causes identified, documented and addressed. The process needs early warning indicators, classification by priority and severity, assigned roles and communication plans. Article 19 requires reporting of major incidents to the competent authority using templates, with an initial notification and further reports.
Evidence: incident register, classification criteria, root cause reports, the reporting templates you prepared, and exercise records.
What about testing?
Article 24 requires a sound and comprehensive digital operational resilience testing programme as part of the ICT risk framework, applied risk based. Article 25 lists tests that can be included, such as vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, source code reviews where feasible, scenario based tests and penetration testing.
Evidence: the programme document, schedule, scan and test reports, remediation tracking.
What is the register of information?
Article 28 starts from a principle: you remain fully responsible for compliance even when you outsource ICT services. You must maintain a register of information on all contractual arrangements for ICT services from third party providers, distinguishing arrangements supporting critical or important functions from others. You report at least yearly to authorities on new arrangements and categories, and provide the full register on request.
Article 30 lists key contractual provisions: roles and obligations in writing, a clear description of services, whether subcontracting is permitted and conditions, and locations where services and data processing occur, with advance notice of changes, among others. Review each ICT contract against this list and record the result.
A constructed example
A payment institution outsources fraud scoring to a SaaS vendor. Its register row lists the vendor, the service, whether it supports a critical function, the contract date, sub processors and processing locations. The contract review sheet ticks each Article 30 element. A test report shows the vendor's API was part of a scenario based exercise. An exit plan sits next to the entry.
What to do
- Write down which DORA articles apply to you under proportionality.
- Approve and date the ICT risk management framework and name the control function.
- Build the asset inventory and schedule a yearly classification review.
- Define incident classification, templates and a tested reporting path.
- Approve a testing programme and keep every report and fix record.
- Build the register of information and map each contract to Article 30.
- Keep a single evidence index linking every item above.
Safeguard's compliance automation and asset discovery can help organise evidence like inventories, scan history and remediation records, and gives a place to link them to controls. DORA compliance is determined by your supervisor, not by any tool.
Quick check
Does DORA apply to my software company?
Directly, it applies to financial entities. ICT providers are affected through contracts and, for designated critical providers, oversight. Ask your financial customers which clauses they will flow down.
How often must asset classification be reviewed?
Article 8(1) says as needed, and at least yearly.
Sources
- Regulation (EU) 2022/2554 (DORA), EUR-Lex, fetched 18 October 2026
Last reviewed: 18 October 2026.
