Skip to main content
Change Risk Intel
Compliance

DORA Change Management Checklist for Resilience Teams

The Change Risk Intel Desk · 18 min read

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 a follow-up report due within 72 hours and a final report within one month (Commission Implementing Regulation (EU) 2024/2956). Penalties for non-compliance with the ICT risk management, incident-reporting, or testing provisions can reach 2% of an entity’s total annual worldwide turnover, and individual executives can be fined directly (regulation-dora.eu, DORA for Banks 2026 penalty summary). 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:

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

This structure follows the ESAs’ own framing of the regulation (EIOPA, “ESAs publish first set of rules under DORA for ICT and third-party risk management and incident classification”; PwC, DORA five pillars summary). The Level 1 text (the regulation itself) sets the obligations; roughly 13 Level 2 regulatory and implementing technical standards (RTS/ITS), developed jointly by the ESAs in two batches submitted in January and July 2024, translate those obligations into specific thresholds, formats, and templates — and all of them became applicable on the same January 17, 2025 date regardless of when each standard was individually finalized (Glocert International, “DORA RTS & ITS Technical Standards Tracker”).

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 change management policies. Article 9 requires financial entities to continuously monitor and control the security and functioning of ICT systems, and to design, procure, and implement ICT security policies, procedures, protocols, and tools that “minimise the impact of ICT risk” (EUR-Lex, Regulation 2022/2554). The joint RTS on the ICT risk management framework, developed under Article 15, is explicit that this includes a documented change management policy and procedure — covering acquisition, development, maintenance, and testing of ICT systems before deployment — approved by the management body (ESMA/EBA/EIOPA Joint Committee, “Joint SH Advice on DORA RTS ICT risk management”). 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, so ICT systems and data can be restored “with minimum downtime” and “limitation of losses” following disruption (EUR-Lex, Regulation 2022/2554). 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.

Article 17 — ICT-related incident management process. Article 17 requires a written, management-body-approved process to “detect, manage and notify ICT-related incidents,” recording every incident and identifying root causes (RegRadar, “DORA Article 17 in practice”). This is where change-caused incidents get pulled into regulatory scope. The RTS on classification of major ICT-related incidents — Commission Delegated Regulation (EU) 2024/1772 — sets primary criteria (clients affected, data-loss relevance, reputational impact, and duration/downtime) that jointly determine whether an incident is “major” and therefore reportable (RegRadar, citing Commission Delegated Regulation (EU) 2024/1772). The corresponding ITS on notification content and format — Commission Implementing Regulation (EU) 2024/2956 — sets the reporting cadence every change manager should know cold:

Notification stageDeadlineWhat’s required
InitialAs soon as possible; at the latest 4 hours after classification, and within 24 hours of detectionEntity identity, brief facts, estimated impact, emergency measures under way
IntermediateWithin 72 hours of the initial notificationUpdated scope, root-cause hypotheses, containment status, customer-impact estimate
FinalNo later than one month after the initial notificationConfirmed root cause, mitigation, cost estimate, lessons learned, framework updates

(Source: RegRadar, “DORA Article 17 in practice,” citing Commission Implementing Regulation (EU) 2024/2956.) If your organization cannot trace a production incident back to the specific change ticket that caused it within roughly four hours, you cannot meet the initial notification clock — 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. Article 24 requires financial entities to establish, maintain, and review a testing program covering vulnerability assessments, source-code reviews, scenario-based tests, and network security assessments for all ICT systems supporting critical or important functions, at least annually (Noerr, “Hacking by regulation: threat-led penetration testing under DORA”). Articles 26-27 go further for designated entities: they must run threat-led penetration testing (TLPT), in which an authorized red team conducts realistic attacks against live production systems — including outsourced ICT services supporting critical functions — at least once every three years, with results overseen by a control team drawn from the financial entity and, where relevant, its ICT providers (Noerr, DORA TLPT summary). TLPT replaces what was previously a voluntary framework in several member states (such as Germany’s TIBER-DE) with a mandatory EU-wide obligation (Noerr). 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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. Change collision check against the Forward Schedule of Changes. No overlapping change touches the same critical function without an explicit joint risk review.
  7. 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.
  8. 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 — required to hit the Article 17 four-hour classification clock.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. Register of Information entry check. For changes involving a new or materially altered ICT third-party arrangement, confirm the Article 28 Register of Information has been (or will be) updated — this register is a live compliance artifact, not an annual exercise.
  14. 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.
  15. 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.

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 enforced directly by national competent authorities and the ESAs, with statutory fines up to 2% of global turnover and personal liability for individual executives (regulation-dora.eu, penalty table). 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: fixed-clock incident notification to a regulator (Article 17), mandatory resilience testing including TLPT (Articles 26-27), and third-party oversight extending to the Register of Information (Article 28). 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

  1. Map your current change management policy against Articles 9 and 12 and identify every gap between what your CAB checks today and the 15-point checklist above.
  2. 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.
  3. Build the change-to-incident linkage field into your ITSM change record now, so a production incident can be traced to its originating change inside the Article 17 four-hour window.
  4. 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.
  5. 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.
  6. 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.
  7. Cross-train your CAB chair and incident commander on the Article 17 notification cadence (4 hours / 24 hours / 72 hours / 1 month) so nobody is learning the clock during a live incident.
  8. 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.
  9. 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

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 becomes “major” when it meets the primary classification criteria set in the RTS on classification of major ICT-related incidents — thresholds covering clients affected, data-loss relevance, reputational impact, and duration or downtime of a critical function (RegRadar, citing Commission Delegated Regulation (EU) 2024/1772).

How fast do we have to report a major incident?

The initial notification is due as soon as possible, at the latest 4 hours after the incident is classified as major and within 24 hours of detection; an intermediate report follows within 72 hours, and a final report within one month (RegRadar, citing Commission Implementing Regulation (EU) 2024/2956).

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

No. TLPT under Articles 26-27 applies to entities designated by their competent supervisory authority based on risk profile and systemic importance, at a minimum every three years; all in-scope entities still must run the broader Article 24 testing program annually regardless of TLPT designation (Noerr, “Hacking by regulation: threat-led penetration testing under DORA”).

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 with fines up to 2% of global turnover rather than an audit opinion (regulation-dora.eu, penalty table).

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

Tested. Article 12 requires backup policies and recovery procedures to be tested regularly so systems and data can be restored with minimum downtime, not merely written down as a policy document (EUR-Lex, Regulation 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?

ICT risk management, ICT-related incident management/classification/reporting, digital operational resilience testing (including TLPT), ICT third-party risk management, and information-sharing arrangements (PwC UK, DORA five pillars summary; EIOPA).

Sources

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

Published July 21, 2026.