What does DORA require from IT change managers?

DORA Article 9(4)(e) requires documented, risk-based ICT change management so every change is recorded, tested, assessed, approved, implemented and verified in a controlled manner. Delegated Regulation (EU) 2024/1774 Article 17 lists what that procedure must contain, including segregation between approvers and implementers, fall-back plans and post-implementation review of emergency changes. Change managers also need tested backup and restoration procedures (Article 12), a link from change-caused incidents into major-incident classification and reporting (Articles 17-19), and testing of critical systems (Articles 24-27).

DORA Checklist for Change Managers + 90-Day Plan

Updated November 13, 2026: We added a section that maps DORA’s change, patch and hardening requirements to specific change controls, quoting the official text. We also corrected three errors. The 4/24/72-hour reporting deadlines come from Delegated Regulation (EU) 2025/301, not Article 17 or Implementing Regulation 2024/2956. Third-party risk is Articles 28-44, not 24-27. And DORA itself sets no turnover-based fine for financial entities. Every regulatory fact below is now cited to EUR-Lex or the ESAs.

This is operational guidance for change teams, not legal or compliance advice. Confirm how DORA and its technical standards apply to your entity with your competent authority and legal or compliance team.

Why this matters right now

DORA has been directly applicable law across the EU since January 17, 2025, and it does not treat a bad software release as a mere IT problem — it treats it as a supervised regulatory event (Regulation (EU) 2022/2554). A change that causes an outage meeting DORA’s materiality thresholds triggers a formal notification to the competent authority within 4 hours of classification and no later than 24 hours after detection, with an intermediate report due within 72 hours of the initial notification and a final report within one month of the latest intermediate report (Commission Delegated Regulation (EU) 2025/301, Article 5). DORA leaves penalties for financial entities to member states. Article 50 requires each state to give competent authorities sanctioning powers and to set administrative penalties that are “effective, proportionate and dissuasive” (Regulation (EU) 2022/2554, Article 50). For a change manager, that reframes the CAB’s rollback-plan question from “can we recover this system” to “can we recover this system inside the window a regulator will ask us to explain.”

What DORA is, and who it covers

The Digital Operational Resilience Act is Regulation (EU) 2022/2554 of the European Parliament and of the Council, adopted December 14, 2022, and applicable since January 17, 2025 (EUR-Lex, Regulation 2022/2554). Unlike a directive, a regulation is directly binding law in every EU member state without national transposition, so every affected firm hit the same compliance date regardless of where it’s headquartered (EUR-Lex). DORA’s scope is broad: Article 2 lists credit institutions, payment institutions, e-money institutions, investment firms, crypto-asset service providers, insurance and reinsurance undertakings, pension funds, credit rating agencies, and — critically for change managers outside financial services — the ICT third-party providers these entities depend on (EUR-Lex, Regulation 2022/2554, Article 2). PwC estimates the regulation reaches more than 22,000 financial entities and their ICT providers operating in or into the EU (PwC UK). If your company runs a SaaS platform, cloud host, or managed IT service that an EU bank or insurer relies on for a critical function, DORA’s third-party provisions reach you even though you’re not a financial entity yourself.

DORA organizes its requirements into five pillars, each anchored in a specific chapter of the regulation and elaborated through binding technical standards from the three European Supervisory Authorities — EBA, EIOPA, and ESMA — working jointly as the Joint Committee:

Pillar	DORA articles	What it covers
ICT risk management	Articles 5-16	Governance, protection, detection, response, and recovery framework for ICT risk
ICT-related incident management, classification, and reporting	Articles 17-23	Incident detection, classification against materiality thresholds, and regulator notification
Digital operational resilience testing	Articles 24-27	Annual resilience testing program plus threat-led penetration testing (TLPT) for designated entities
ICT third-party risk management	Articles 28-44	Contractual terms, concentration-risk review, and a Union oversight framework for critical ICT providers
Information sharing	Articles 45-49	Voluntary arrangements for sharing cyber threat intelligence among financial entities

The five-pillar grouping is common shorthand (PwC UK). EIOPA’s own overview splits it into six areas, listing oversight of critical ICT third-party providers separately (EIOPA, DORA overview). The regulation sets the obligations, and Commission delegated and implementing regulations drafted by the ESAs fill in the detail. Four of them matter most to change teams. Delegated Regulation (EU) 2024/1774 sets out the ICT risk management framework, including the change, patch and hardening requirements mapped below. Delegated Regulation (EU) 2024/1772 sets the major-incident classification criteria and thresholds. Delegated Regulation (EU) 2025/301 sets the reporting deadlines. Implementing Regulation (EU) 2024/2956 provides the register-of-information templates.

Which DORA articles actually govern your change process

Most DORA commentary is written for CISOs and compliance officers. Four articles, though, land squarely on the change manager’s desk.

Article 9 — protection and prevention, including ICT change management. Article 9(4)(e) is the one sentence in DORA written for change managers. It requires financial entities to “implement documented policies, procedures and controls for ICT change management, including changes to software, hardware, firmware components, systems or security parameters, that are based on a risk assessment approach and are an integral part of the financial entity’s overall change management process, in order to ensure that all changes to ICT systems are recorded, tested, assessed, approved, implemented and verified in a controlled manner” (Regulation (EU) 2022/2554, Article 9). Article 17 of Delegated Regulation (EU) 2024/1774 then lists the elements that procedure must include (Delegated Regulation (EU) 2024/1774). The mapping section below covers each one. This is the article your CAB charter, change taxonomy, and pre-implementation testing standard need to trace back to in a compliance mapping.

Article 12 — backup, restoration, and recovery. Article 12 requires financial entities to develop backup policies and recovery procedures, and to test them regularly, and states that “testing of the backup procedures and restoration and recovery procedures and methods shall be undertaken periodically,” with the aim of restoring ICT systems and data “with minimum downtime, limited disruption and loss” (Regulation (EU) 2022/2554, Article 12). This is the direct regulatory hook for the rollback/backout section of a change ticket. A change record that says “rollback: revert to previous version” without a tested procedure, an owner, and a time estimate does not meet the spirit of Article 12 — and if that change causes a major incident, the backup and restoration narrative is one of the first things supervisors ask to see in the final incident report.

Articles 17-19 — incident management, classification and reporting. Article 17 requires financial entities to “define, establish and implement an ICT-related incident management process to detect, manage and notify ICT-related incidents” (Regulation (EU) 2022/2554, Article 17). This is where change-caused incidents enter regulatory scope. Article 18 sets the classification criteria: clients and transactions affected, duration and downtime, geographical spread, data losses, criticality of the services affected, and economic impact (Regulation (EU) 2022/2554, Article 18). Delegated Regulation (EU) 2024/1772 turns those into thresholds. An incident is major if it affects critical services and either involves successful malicious unauthorised access that may result in data losses, or meets two or more of the other materiality thresholds (Delegated Regulation (EU) 2024/1772, Article 8). Article 19(4) defines the three reports, and Delegated Regulation (EU) 2025/301 sets their deadlines:

Report	Deadline (Delegated Regulation 2025/301, Article 5)	When it is triggered (DORA Article 19(4))
Initial notification	As early as possible, and within 4 hours of classifying the incident as major, but no later than 24 hours after becoming aware of it	After the incident is classified as major
Intermediate report	Within 72 hours of the initial notification	When the incident’s status or handling has changed significantly, with updates as relevant status updates become available
Final report	No later than one month after the latest updated intermediate report	When root cause analysis is complete and actual impact figures can replace estimates

(Sources: Regulation (EU) 2022/2554, Article 19; Delegated Regulation (EU) 2025/301, Article 5.) If an incident is only classified as major more than 24 hours after detection, the initial notification is due within 4 hours of classification. Entities that cannot meet a deadline must inform the competent authority and explain why (Delegated Regulation (EU) 2025/301, Article 5). If your organization cannot trace a production incident back to the specific change ticket that caused it within roughly four hours, you will struggle to meet the initial notification deadline — which means the CAB’s change-to-incident linkage discipline is now a regulatory control, not just a good operational habit.

Articles 24-27 — digital operational resilience testing, including TLPT. Financial entities other than microenterprises must ensure “at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions” (Regulation (EU) 2022/2554, Article 24). Article 25 lists the kinds of tests the programme can include, from vulnerability scans and source code reviews to scenario-based, performance, end-to-end and penetration testing. Entities that their competent authority identifies under Article 26(8) must also run threat-led penetration testing (TLPT) at least every three years. Each test covers several or all critical or important functions and is “performed on live production systems supporting such functions” (Regulation (EU) 2022/2554, Article 26). For change managers, this means testing evidence for any system in TLPT scope needs to be preserved and change-linked, since red-team findings frequently trace back to a specific configuration or deployment change.

The 12-15 point CAB checklist for DORA compliance

Use this as a standing verification list for any change touching a system that supports a critical or important function under DORA. It’s not a substitute for legal review — it’s the operational layer a CAB chair can actually check in a meeting.

Change policy traceability. Confirm the change management policy invoked for this ticket is the version currently approved by the management body, per the Article 9 ICT risk management framework.
Risk classification documented. Every change has a documented risk rating tied to the criticality of the ICT asset or business function it touches — not a generic severity field left at the default.
Backup verification before change. A current, tested backup of affected systems and data exists and is confirmed before the change window opens, per Article 12.
Rollback/restoration plan attached, not implied. The ticket names a specific rollback procedure, an owner, and an estimated restoration time — “revert to previous build” is not a plan.
Rollback plan has been tested, not just written. At minimum for TLPT-in-scope or critical-function systems, the rollback procedure has been executed in a non-production test at some point in the last 12 months.
Change collision check against the Forward Schedule of Changes. No overlapping change touches the same critical function without an explicit joint risk review.
Third-party/CIF classification confirmed. If the change touches a system provided by an ICT third party, confirm whether that service is classified as supporting a critical or important function (CIF) under Article 28, since CIF status changes the contractual and notification obligations that apply.
Incident-linkage field populated. The change record includes a field that can be queried later to link any resulting incident back to this specific change — so the team can classify the incident quickly enough to meet the 4-hour initial-notification deadline in Delegated Regulation 2025/301.
Materiality pre-assessment for high-blast-radius changes. For changes to systems supporting a large client base or a critical function, the CAB pre-reviews what would trigger the Article 18/RTS 2024/1772 major-incident thresholds if the change fails, so the incident team isn’t calculating this cold during an outage.
Testing evidence attached for CIF systems. Evidence that the change was tested per the Article 24 testing program (vulnerability scan, scenario test, or code review as applicable) before deployment to a critical-function system.
TLPT scope flag. If the target system is in a designated TLPT scope, the CAB confirms the change doesn’t conflict with an upcoming or in-progress TLPT exercise window.
Management-body escalation threshold defined. The ticket specifies at what point during implementation the change gets escalated above the CAB to the accountable executive, consistent with Article 5’s requirement that the management body bear ultimate responsibility for ICT risk.
Register of Information entry check. For changes involving a new or materially altered ICT third-party arrangement, confirm the register of information required by Article 28(3) has been (or will be) updated. The standard templates are in Implementing Regulation (EU) 2024/2956. The register covers all contractual arrangements for ICT services and must be kept up to date.
Post-implementation review scheduled. Every significant or major change to a critical-function system has a calendared post-implementation review, feeding the Article 13 “learning and evolving” requirement.
Audit trail retention confirmed. Change records, test evidence, and approval sign-offs for CIF-supporting systems are retained per your firm’s DORA-aligned retention policy, since supervisors can request historical evidence during an examination.

Teams building this into an existing agenda template can start from our CAB agenda generator, which produces a pre-filled structure you can extend with these DORA-specific fields, and score individual changes for blast radius before they reach the board with our change risk score tool.

DORA requirements mapped to change controls

DORA itself states the change management obligation in one sentence. The specific change, patch and hardening requirements are in Delegated Regulation (EU) 2024/1774, the RTS on the ICT risk management framework. The tables below map each requirement to the change-record field or CAB control that would evidence it. The left column paraphrases the regulation closely. The right column is our suggestion for how to evidence it, not regulatory text.

ICT change management (RTS Article 17)

Article 17(1) applies to “all changes to software, hardware, firmware components, systems, or security parameters” and requires the change procedure to include each of the following (Delegated Regulation (EU) 2024/1774, Article 17):

RTS 2024/1774 Art. 17(1)	Requirement	Change control and evidence
(a)	Verify whether ICT security requirements have been met	Security-requirements checkbox or security review sign-off on the change record, and a mandatory field for changes to CIF systems
(b)	Independence between functions that approve changes and those that request and implement them	Workflow rule that blocks the requester or implementer from approving their own change, plus an approval log showing distinct approvers
(c)	Roles and responsibilities so changes are specified and planned, an adequate transition is designed, changes are tested and finalised in a controlled manner, and quality assurance is effective	Named change owner, implementer and tester; a transition or deployment plan; attached test evidence; a QA or peer-review step before approval
(d)	Documentation and communication of purpose and scope, implementation timeline and expected outcomes	Required fields for purpose/scope, scheduled window and expected outcome or success criteria, plus a stakeholder notification record
(e)	Fall-back procedures and responsibilities, including aborting changes or recovering from unsuccessful ones	Backout plan with an owner, abort criteria and a restoration time estimate (see checklist items 3-5)
(f)	Procedures, protocols and tools for emergency changes with adequate safeguards	A defined emergency change model with its own approval authority and minimum checks
(g)	Document, re-evaluate, assess and approve emergency changes after implementation, including workarounds and patches	Retrospective approval task opened automatically for every emergency change, with a closure deadline tracked on the CAB agenda
(h)	Identify the potential impact on existing ICT security measures and whether additional measures are needed	Security-impact assessment field, with a follow-up control change raised where needed

Central counterparties and central securities depositories have an extra obligation. Under Article 17(2), they must also stress-test after significant changes.

Patch and vulnerability management (RTS Article 10)

Patches are changes, so they go through the Article 17 procedure as well. Article 10 adds patch-specific requirements (Delegated Regulation (EU) 2024/1774, Article 10):

RTS 2024/1774 Art. 10	Requirement	Change control and evidence
10(2)	Automated vulnerability scanning and assessments, at least weekly for ICT assets supporting critical or important functions	Scan schedule and the latest scan date for each CIF asset, linked to the CMDB record
10(2)	Prioritise deployment of patches by criticality, the asset’s classification and its risk profile	Patch priority on the change record derived from the asset’s criticality, not just the vendor’s severity
10(4)(a)	Identify and evaluate available patches and updates, using automated tools to the extent possible	Patch intake feed (vendor advisories, scanner output) that creates candidate changes
10(4)(b)	Emergency procedures for patching and updating	Emergency patch path mapped to the emergency change model in (f) and (g) above
10(4)(c)	Test and deploy patches and updates	Test evidence attached before production deployment, with deployment verification after
10(4)(d)	Deadlines for installing patches and escalation procedures if they cannot be met	Due date by priority tier, and an escalation or risk-acceptance record when a patch misses it

Article 10 also requires monitoring how ICT third-party providers handle vulnerabilities, tracking third-party and open-source libraries, and recording detected vulnerabilities. For monthly cadence planning, see our November 2026 Patch Tuesday CAB plan.

Hardening and secure configuration (RTS Articles 11 and 13)

DORA doesn’t use the word “hardening checklist,” but the RTS sets out two configuration requirements that change control has to protect. Article 11(2)(b) requires “a secure configuration baseline for ICT assets” that minimises exposure, plus measures to verify regularly that those baselines are effectively deployed. Article 13 requires a secure configuration baseline for all network components and hardening of the network and network devices in line with vendor instructions, applicable standards and leading practices (Delegated Regulation (EU) 2024/1774, Articles 11 and 13). In change terms, any change that alters a baseline needs the security-impact assessment in Article 17(1)(h) and an updated baseline record. A drift check after implementation also shows the deployed configuration still matches the approved baseline.

Simplified framework entities

Entities under DORA’s simplified ICT risk management framework (Article 16(1), such as small and non-interconnected investment firms) follow Title III of the RTS instead. Article 38 of the RTS requires them to have an ICT change management procedure that ensures “all changes to ICT systems are recorded, tested, assessed, approved, implemented, and verified in a controlled manner” (Delegated Regulation (EU) 2024/1774, Article 38). The table above is still a useful structure, but the detailed Article 17 list doesn’t apply to them in the same form.

How does DORA relate to SOX and SOC 2 for multi-regime firms?

Firms subject to DORA are frequently also subject to U.S. Sarbanes-Oxley (SOX) IT general controls or undergoing SOC 2 audits, and the overlap is real but not total. SOX’s IT general controls framework requires documented, tested change management controls to support the integrity of financial reporting systems — see our SOX change control requirements mapped to ITSM for the control-by-control detail. SOC 2’s Common Criteria (CC8.1) similarly requires organizations to authorize, design, develop, test, and approve changes to infrastructure and software, which we cover in SOC 2 change management controls and audit questions. Both frameworks and DORA converge on the same underlying discipline: documented authorization, tested rollback, and an auditable record of who approved what and why.

The practical difference is scope and enforcement. SOX and SOC 2 controls give auditors and investors confidence in financial reporting and service commitments, enforced through audit opinions and, for SOX, SEC oversight of public companies. DORA is a supervisory regime. National competent authorities enforce it using the administrative penalties and remedial measures each member state sets under Article 50, and the ESAs directly oversee critical ICT third-party providers (Regulation (EU) 2022/2554, Articles 35 and 50). A firm that already runs disciplined SOX ITGC or SOC 2 change management is most of the way to DORA’s Article 9 expectations — but DORA adds obligations neither U.S. framework requires: deadline-driven incident reporting to a regulator (Article 19 and Delegated Regulation 2025/301), mandatory resilience testing including TLPT for identified entities (Articles 24-27), and a register of information covering all ICT third-party arrangements (Article 28(3)). Don’t assume a clean SOC 2 report closes the DORA gap analysis — map the controls article by article, and expect the incident-reporting and TLPT pillars to require net-new process even at a mature ITGC shop.

What to do in the next 90 days

Map your current change management policy against Article 9(4)(e), Article 12 and RTS 2024/1774 Articles 10 and 17, using the mapping tables above, and identify every gap between what your CAB checks today and those requirements.
Inventory every system supporting a critical or important function (CIF) and cross-reference it against your ICT third-party contracts to identify Article 28 Register of Information gaps.
Build the change-to-incident linkage field into your ITSM change record now, so a production incident can be traced to its originating change quickly enough to meet the 4-hour initial-notification deadline. If you are evaluating ITSM platforms at the same time, our change management software comparison for regulated industries compares EU data residency and SoD support across 10 vendors.
Pressure-test one rollback plan per critical system in a non-production environment and document the actual restoration time against your Article 12 recovery-time assumptions.
Confirm your TLPT designation status with your compliance or risk function — not every entity is designated, but if yours is, align change freezes around the testing window.
Add a materiality pre-assessment step to CAB review for any change touching a CIF system, using the Article 18/RTS 2024/1772 thresholds as the working checklist.
Cross-train your CAB chair and incident commander on the reporting deadlines in Delegated Regulation 2025/301 (4 hours after classification and no later than 24 hours after awareness, then 72 hours, then one month) so nobody is learning the clock during a live incident.
Reconcile your DORA control mapping against existing SOX ITGC or SOC 2 CC8.1 evidence to avoid duplicating audit work, then document the net-new controls DORA requires on top.
Schedule a tabletop exercise simulating a change-caused major incident, running it end-to-end through classification, notification, and the CAB’s post-implementation review process.

Frequently asked questions

What is a DORA compliance checklist?

DORA has no official checklist. The phrase usually means a list of controls an entity uses to show that its processes meet the regulation and its technical standards. For change management, the most specific requirements are Article 9(4)(e) of DORA and Article 17 of Delegated Regulation (EU) 2024/1774. The mapping tables above turn those into change-record fields and CAB checks (Regulation (EU) 2022/2554; Delegated Regulation (EU) 2024/1774).

Does DORA have specific patch management requirements?

Yes. Article 10 of Delegated Regulation (EU) 2024/1774 requires automated identification and evaluation of patches where possible, emergency patching procedures, testing before deployment, and installation deadlines with escalation if they are missed. Vulnerability scanning must run at least weekly on ICT assets supporting critical or important functions (Delegated Regulation (EU) 2024/1774, Article 10).

Does DORA apply to companies outside the EU?

Yes, indirectly. DORA directly binds EU financial entities, but its ICT third-party provisions extend to any ICT provider — including non-EU cloud, SaaS, or managed service vendors — that supports a critical or important function for an in-scope EU financial entity, and critical providers can be designated for direct oversight under the Union Oversight Framework (EUR-Lex, Regulation 2022/2554, Article 31).

An incident is major if it affects critical services and either involves successful malicious unauthorised access that may result in data losses, or meets two or more of the other materiality thresholds. The thresholds cover clients affected, reputational impact, duration and downtime, geographical spread, data losses and economic impact. Recurring incidents with the same apparent root cause can also count together as one major incident (Delegated Regulation (EU) 2024/1772, Article 8).

How fast do we have to report a major incident?

The initial notification is due as early as possible, within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it. The intermediate report is due within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report (Delegated Regulation (EU) 2025/301, Article 5).

Is threat-led penetration testing mandatory for every financial entity?

No. TLPT applies only to entities that competent authorities identify under Article 26(8), based on impact, financial stability concerns and ICT risk profile. Those entities run it at least every three years. Financial entities other than microenterprises must still test all ICT systems and applications supporting critical or important functions at least yearly under Article 24 (Regulation (EU) 2022/2554, Articles 24 and 26).

What’s the difference between DORA and SOC 2 for change management?

SOC 2’s CC8.1 requires documented authorization, testing, and approval of infrastructure and software changes as part of a service organization’s controls audit, while DORA imposes statutory obligations including fixed-clock regulatory incident reporting and mandatory resilience testing, enforced by financial supervisors through penalties set by member states under Article 50 rather than through an audit opinion (Regulation (EU) 2022/2554, Article 50).

Do backup and rollback plans need to be tested, or just documented?

Tested. Article 12(2) says testing of backup procedures and of restoration and recovery procedures and methods “shall be undertaken periodically,” so documenting them isn’t enough (Regulation (EU) 2022/2554, Article 12).

When did DORA take effect?

DORA was adopted on December 14, 2022, and became directly applicable across all EU member states on January 17, 2025 (EUR-Lex, Regulation 2022/2554).

What are DORA’s five pillars?

The common five-pillar summary is ICT risk management, ICT-related incident management and reporting, digital operational resilience testing (including TLPT), ICT third-party risk management, and information sharing (PwC UK). EIOPA’s overview lists oversight of critical ICT third-party providers as a sixth area (EIOPA, DORA overview).

Sources

#dora #eu-regulation #operational-resilience #compliance #change-management

Published July 21, 2026. Last updated November 13, 2026.