DORA technical controls checklist for financial sector engineers

DORA, the EU Digital Operational Resilience Act, requires financial entities to manage ICT risk with specific technical practices: continuous monitoring and protection, anomaly detection, backups with segregated restore systems, an incident process, resilience testing at least yearly and a register of ICT third party arrangements. This checklist maps those duties to engineering tasks.

What does DORA require, in engineering terms?

DORA is Regulation (EU) 2022/2554. It applies to financial entities and is accompanied by technical standards and templates that supervisors rely on. Some duties differ for microenterprises and for particular entity types such as central counterparties. Read the articles that apply to your entity type and your national supervisor's expectations. I fetched the article texts below from an unofficial reproduction, so check wording against EUR-Lex.

What is the checklist, article by article?

Protection and prevention (Article 9)

• Continuously monitor and control the security and functioning of ICT systems and tools.
• Document an information security policy covering availability, authenticity, integrity and confidentiality.
• Build network and infrastructure management so connections can be severed or segmented quickly to limit contagion. The text speaks of isolating affected assets, where appropriate automatically.
• Limit logical and physical access to what legitimate functions need, with administered access rights.
• Use strong authentication and protect cryptographic keys, with encryption based on data classification and risk assessment.
• Operate documented change management for software, hardware, firmware and security parameters: recorded, tested, assessed, approved, implemented and verified.
• Keep documented patch and update policies. Evidence: policy, network diagrams, access reviews, key management standard, change tickets, patch reports.

Detection (Article 10)

• Mechanisms to promptly detect anomalous activities, including network performance issues and ICT incidents, and identify material single points of failure.
• Multiple layers of control, alert thresholds and criteria that trigger incident response, with automatic alerts to responders.
• Sufficient resources to monitor user activity and anomalies.
• Regular testing of the detection mechanisms. Evidence: alert rules, escalation records, detection test results.

Backup and recovery (Article 12)

• Documented backup policies setting scope and minimum frequency by criticality, and restoration and recovery procedures.
• Restore on systems that are physically and logically segregated from the source systems, protected from unauthorised access and corruption.
• Redundant ICT capacity adequate for business needs, except that microenterprises assess the need by risk profile. Evidence: backup policy, restore test records, architecture diagram of the segregated restore path.

Incident management (Article 17)

• A process to detect, manage and notify ICT incidents, recording all incidents and significant cyber threats.
• Early warning indicators, classification by priority, severity and service criticality, assigned roles, communication plans, escalation, and reporting of major incidents to senior management and the management body.
• Root cause analysis and follow up. Evidence: incident register, classification rules, management reports.

Reporting (Article 19)

• Major ICT incidents are reported to the competent authority using prescribed templates, and clients are informed without undue delay where their financial interests are affected. Know which authority is yours and the exact timelines in the technical standards, which this article refers to.

Testing (Articles 24 and 25)

• A digital operational resilience testing programme including vulnerability assessments and scans, open source analyses, network security assessments, gap analyses, physical security reviews, questionnaires and scenario based tests, among others.
• Appropriate tests on all ICT systems and applications supporting critical or important functions at least yearly, other than for microenterprises.
• Threat led penetration testing applies to entities designated under the later articles. Check whether yours is one. Evidence: test plans, reports, remediation tickets.

Third party risk (Articles 28 and 30)

• Maintain a register of information on all contractual arrangements for ICT services from third party providers, at entity and group levels where relevant, and make it available to the competent authority on request. Entities report to authorities at least yearly on new arrangements and provider categories.
• Contract terms must cover items such as provider cooperation in your testing, where relevant. Evidence: register extracts, contract checklists, review notes.

Which tasks do engineering teams skip?

• Restoring on segregated systems. Many teams test restore in the same environment.
• Classification of data. Encryption choices should follow it, so it has to exist.
• Testing the detection itself. Article 10 asks for it.
• Treating the register as procurement's problem. It needs technical facts, such as which services support critical functions.
• Single points of failure. Article 10 asks you to identify them.

What to do

1. Confirm your entity type, proportionality and supervisor, and read the articles that apply.
2. Build an inventory of ICT assets, services and third party providers, marking critical or important functions.
3. Close the cheap gaps: change records, patch policy, access review, restore on segregated systems.
4. Define incident classification and the path to your authority.
5. Write the annual test programme and book the first tests.
6. Populate the third party register with a named owner.
7. Report status to the management body every quarter.

Quick check

How Safeguard helps automate this

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, which saves the team time. For Article 9 patching and Article 25 vulnerability testing, technical evidence comes from your real code and dependencies: scans, SBOMs and reachability. Safeguard's agent can open tested fix pull requests for vulnerable dependencies and other findings. It is off by default, every category starts on Manual, and you choose which categories run automatically and the approval level. Safeguard helps prepare and keep evidence ready. Your supervisor decides compliance. Book a call.

Sources

• DORA Article 9
• DORA Article 10
• DORA Article 12
• DORA Article 17
• DORA Article 19
• DORA Article 24
• DORA Article 25
• DORA Article 28
• DORA Article 30

Last reviewed: 18 October 2026.