The Digital Operational Resilience Act (DORA) has applied since 17 January 2025, and for a DevOps lead it translates into three build tasks: incident records good enough to support regulatory reports, tested recovery and change processes, and dependency data about third-party ICT services. Start with the incident timeline, because that is where regulators look first.
Where does DORA touch operations?
EIOPA states that DORA applies to 20 types of financial entity and to ICT third-party service providers, with the aim that firms can withstand, respond to and recover from ICT disruptions. The regulation is Regulation (EU) 2022/2554, and its text covers ICT risk management, incident reporting, resilience testing and third-party risk.
If you run systems for a financial entity, or provide them as a supplier, the regulation reaches your runbooks.
What does incident reporting need from you?
Article 19 requires financial entities to report major ICT-related incidents to their competent authority. The reporting criteria and templates are set in implementing standards, so check the current technical standards for thresholds and timings rather than relying on a summary.
What DevOps controls is the raw material: when the incident started, when it was detected, what services and customers it affected, what the cause was and when it ended. A constructed example: an outage of a payment API lasts 70 minutes. The on-call channel has timestamps, the status page was updated at minute 25, and the deploy log shows a change at minute zero. If those three sources disagree, nobody can build a credible report. Align clocks, keep a single incident timeline, and record the classification decision with its reason.
What about recovery and testing?
The regulation's text requires financial entities to document and review the ICT risk management framework at least once a year, and to run in-depth assessments after major changes in infrastructure and processes. It also provides for advanced testing based on threat-led penetration testing for entities meeting specified criteria, with microenterprises exempt.
For you that means recovery that has been exercised, not just written: restore from backup into a clean environment, fail over a region, rebuild from source. Record the date, duration and result of each exercise. Change management is the other pillar. Reviewed, traceable changes with rollback plans make both audits and incident analysis much easier.
Which supplier data will you be asked for?
Financial entities must keep a register of information on contractual arrangements for ICT services from third parties, and supervisors can ask for it. You will be asked which cloud, SaaS and open source components your service depends on, where they run and who the subcontractors are. A current software bill of materials and a hosting map answer much of that.
What should a recovery exercise record?
Write the exercise like a small experiment. State the scenario, the objective, such as restore the primary database within a target time, and the success criterion. Record start and end times, who took part, what went wrong and what you changed afterward. Attach logs or screenshots so the record stands on its own.
Run at least one exercise that surprises people. A drill that follows a well-rehearsed script proves the script works. One that removes a key person, a dependency or a tool shows what the team really depends on. Regulators and customers value evidence that you learn from exercises, so keep a short log of improvements made as a result.
How to check or apply this
- Unify incident timelines: one source of truth, synchronized clocks, recorded classification.
- Draft an incident notification template with the fields a customer would need.
- Schedule and record recovery exercises at least yearly, and after major changes.
- Tie every production change to a ticket, review and rollback plan.
- Produce a dependency and subprocessor list for each service, automatically if possible.
- Review which services would be in a customer's threat-led test and agree access rules.
- Check the current implementing standards for reporting thresholds with counsel.
Safeguard's SBOM and dependency scanning can generate the component inventory, and its compliance automation can help keep exercise and review evidence together.
Quick check
Which incidents must be reported under DORA?
Major ICT-related incidents, as defined by classification criteria in supporting technical standards. Check the current standards for thresholds.
Does DORA require threat-led penetration testing for everyone?
No. The text limits it to entities meeting specified criteria and exempts microenterprises.
Sources
Last reviewed: 18 October 2026.
