DORA ICT change management requirements, what auditors test

What DORA change management requirements mean for your organization

If your organization is a financial entity or an ICT provider and a supervisor or customer has asked how you control changes, the answer starts with Article 17 of Delegated Regulation (EU) 2024/1774, which requires a documented change procedure covering every change, with approvers kept separate from the people who request and implement changes, fall-back plans and post-change review. DORA sets no certification scheme, so your organization owns these controls and an independent assessor tests them; implementation partners can prepare the procedure, tooling and evidence, but only the assessor reaches a view on whether it works. DORA has applied since 17 January 2025, so supervisors already expect a working process rather than a plan. The effort depends on how your change estate is built. The number of systems that support critical or important functions drives how many change records, test plans and rollback procedures you must maintain. Your change volume and the share of emergency changes determine how much review-after-implementation work lands on approvers each month. A regulated entity with a small set of stable, vendor-hosted services carries a different load from one running self-hosted platforms with frequent releases. Central counterparties and central securities depositories also carry the extra duty to stress-test ICT systems after significant changes, which adds recurring test effort. Before scoping, confirm with your supervisor or customer which of your systems they treat as supporting critical or important functions, how they count emergency changes, and what evidence they expect for approver separation. Ask any implementation partner for a written scope that names the systems in the change procedure, the ticketing and approval workflow, the people who sign off, and who maintains the records after handover. Check the regulation text directly at Regulation (EU) 2022/2554 on EUR-Lex and the technical standard at Delegated Regulation (EU) 2024/1774 on EUR-Lex for the exact obligations that apply to your entity type.

How emergency changes and post-change stress testing are handled

Article 17 of Delegated Regulation (EU) 2024/1774 sets the rules for changes that cannot wait for the normal path, and Article 15 sets the project controls around larger change programmes. The four cards below cover the emergency path, the review that follows it, the stress-testing duty for central counterparties and central securities depositories, and project-level change control.

Emergency change safeguards

An emergency change is one that must go in faster than the standard approval path allows, usually to restore service or close an active vulnerability. Article 17 requires that emergency changes still follow safeguards, so the emergency path is a defined procedure with its own minimum controls, not an informal bypass. Check who can declare an emergency, what minimum record is made before the change is applied, and how the security check is kept even when timing is tight. Confirm the emergency criteria in writing before an incident forces the question.

After-the-fact review and approval

Because an emergency change is applied before full approval, the regulation requires that it is reviewed and approved after implementation. This closes the gap between speed and accountability. The review should confirm what was changed, why the normal path was skipped, whether the security impact was assessed, and whether the fall-back plan was ready. Record the reviewer as someone independent of the implementer, and keep the review linked to the original change record so auditors can trace the full sequence.

Stress testing after significant changes

Central counterparties and central securities depositories must stress-test their ICT systems after significant changes, under the same Article 17. Other financial entities are not subject to this specific duty, but the stress-test requirement shows what supervisors expect of market infrastructures. For those in scope, define in advance what counts as a significant change, which scenarios the test covers, and who signs off the results before the system returns to full production. Confirm whether your entity is a CCP or CSD before assuming this duty applies.

Project-level change control

Article 15 requires an ICT project management policy covering planning, project risk assessment, milestones, change management and testing. Security testing and approval must happen before production, and projects that affect critical or important functions must be reported to the management body. This is where single changes are grouped into programmes, so the control sits above individual tickets. Check that project records show the security test evidence and that reporting to the management body is scheduled and minuted.

How an assessor tests change management

The sequence starts with a sample of real changes and follows each one from request to verification, so the assessor can confirm that the documented procedure operated as written, not only that it exists on paper.

Select a sample of changes across types
The assessor first asks for the complete change register for the period under review and checks that it is reasonably complete, for example by reconciling it against deployment logs, repository merge records and infrastructure tickets. From that population the assessor draws a sample that spans standard, normal and emergency changes, and changes to software, hardware, firmware, systems and security parameters. The output is a written sample list with the reason each change was chosen, which the organization can review before testing starts.
Trace each change from request to approval
For each sampled change, the assessor follows the record from the original request through to the approval step and checks that the request states the purpose, scope, timeline and expected outcome. The assessor looks for the security requirements verification that Article 17 expects to happen before approval. The output is a per-change trace showing the request, the approval and any gaps, such as a missing scope statement or an approval dated after implementation.
Confirm approver and implementer are separate people
The assessor compares the identity recorded as requester or implementer with the identity recorded as approver for every sampled change. The check covers both the ticketing system and the system logs that show who actually deployed the change, because a shared or privileged account can hide overlap. The output is a segregation result for each change, along with any exceptions and the access rights that allowed them.
Check fall-back and abort plans
For each sampled change, the assessor looks for a documented fall-back or abort procedure that was written before implementation and that matches the change's actual risk. Where testing was performed, the assessor checks that the test evidence and quality assurance sign-off are attached to the record. The output is a list of changes with usable rollback documentation and a list of changes where the plan is missing, generic or copied from another change.
Review emergency change records
The assessor pulls every emergency change in the period and checks that each one followed the safeguards the organization defined for urgent work, and that each was reviewed and approved after implementation. The assessor compares the timestamps of the implementation and the post-implementation approval, and checks whether any emergency change was later rolled into a normal change without review. The output is an emergency change exception list with the approver and review date for each item.
Review the impact assessment on existing security measures
For each sampled change, the assessor reads the impact assessment and checks that it considers how the change affects existing security measures, such as access controls, logging, encryption and network segmentation. The assessor then compares the assessment with the actual scope of the change in the deployment record, looking for systems touched by the change that the assessment does not mention. The output is an impact assessment result per change and a list of cases where the assessment understated the scope.
Document findings and request remediation evidence
The assessor consolidates the results into findings, each tied to a sampled change or a population-level gap, and asks the organization to respond with remediation evidence. For central counterparties and central securities depositories, the assessor also checks whether stress testing followed significant changes. The output is a findings report with the evidence requested for each item, which the organization can prepare against before the next review.

Which evidence shows a change was controlled

An assessor tests change management by asking for records, not descriptions of intent. The cards below cover the artifacts that, taken together, show every change was requested, checked, approved by someone other than the implementer, tested, rolled back if needed and verified afterwards. Confirm with your own change process which of these your tooling produces automatically and which need manual sign-off.

Change tickets with required fields

Each change needs a ticket that records its purpose, scope, timeline and expected outcome, as Article 17 of Delegated Regulation (EU) 2024/1774 requires. Make the required fields mandatory in the workflow so a ticket cannot close without them. Check that the ticket also records the change's assessed impact on existing security measures, since a sampled ticket missing this field is an easy finding for an assessor.

Approval records showing separated roles

The approval record should show who requested the change, who approved it and who implemented it, with the three roles held by different people. Assessors look for this separation in the audit trail itself, not in the policy document. Confirm that your tool stores approver identity and timestamp per step and that administrators cannot approve their own changes.

Test results and QA sign-off

Article 17 requires controlled testing and defined quality assurance roles before a change reaches production. Keep the test plan, test results and the QA sign-off linked to the originating ticket. For changes to production systems, the record should show the environment tested and the date of testing, so the evidence ties to what was actually deployed.

Rollback plans attached to tickets

Each change should carry a documented fall-back and abort procedure, showing how the system returns to its prior state if the change fails. Attach the rollback plan to the ticket before approval, not after implementation. An assessor will compare the plan against what happened, so record whether a rollback was executed and its outcome.

Emergency change review records

Emergency changes must follow safeguards and be reviewed and approved after implementation. Keep a separate record type or flag for these changes, with the reason for urgency, who authorized the work at the time, and the post-implementation review date and approver. Retrospective approvals without a recorded reason are a common gap to test for.

Post-change verification records

Verification shows the change achieved its expected outcome and did not weaken existing security measures. Record the verification check, its result and the person who performed it against the ticket. For central counterparties and central securities depositories, Article 17 also requires stress testing of ICT systems after significant changes, so record those results against the relevant change.

Who owns change management under DORA

The financial entity remains responsible for its ICT change management procedure under the ICT risk management framework. Article 17 of Delegated Regulation (EU) 2024/1774 requires the procedure to verify security requirements for every change and to separate the people who approve changes from those who request and implement them. No vendor can take over that accountability, and the management body is answerable for the risk decisions behind each change.

Procedure ownership: The entity writes, approves and maintains the change management policy and decides which change categories, risk levels and approval paths apply.
Approval separation: Named approvers who are independent of implementers must be defined in the entity's own role model, not inferred from a tool default.
Risk decisions: The entity assesses each change's impact on existing security measures and accepts or rejects residual risk.
Emergency change review: Post-implementation review and approval of emergency changes is performed by the entity, with records kept.
Records: The entity holds the change records showing purpose, scope, timeline, expected outcome, fall-back and abort procedures.

Before engaging anyone, check that your own change owner, approver and implementer roles are written down and that the approval separation can be demonstrated from system records.

What change management work costs and what drives it

No DORA-specific cost figure for change management is supplied here, so the sensible starting point is to understand who is paid for what. The largest cost is usually internal time. Change owners must document each change with its purpose, scope, timeline, expected outcome, fall-back and abort procedure, and an assessment of its impact on existing security measures. Approvers must be people other than those who request and implement the change, so the organization needs enough qualified staff in both roles to avoid one person holding both. Those hours recur for every change, not once. Tooling is the second component: a ticketing or change record system, whether commercial or open source, carries licence or hosting costs and the effort to configure workflows, approval routing and reporting. Open-source options such as GLPI, which supports ITIL-style changes, still need installation, integration with monitoring and identity systems, and staff training.

External spend falls into two groups. An implementation partner, if used, should work under a fixed written scope that names the deliverables: the change procedure, the record template, the approval workflow, the emergency change path and the integration work. Ask each bidder to state which of these are included, what the client must provide, and how post-change verification is handled. An independent assessor is a separate cost and is paid only if the entity buys an external review of its change controls. DeployOpen prepares systems and evidence but does not issue assessment reports, so an assessor's fee is additional in any case. The organization owns the control and decides whether an outside review is worth buying.

Several drivers move the total up or down. The number of systems supporting critical or important functions determines how many changes need full documentation, testing and stress testing, and whether central counterparties or central securities depositories are in scope for post-change stress testing. Change volume and the number of teams that can initiate changes drive the size of the approval queue and the need for role separation across teams. Existing tooling matters because a mature change system reduces integration work, while manual processes built on spreadsheets raise both the effort and the risk of gaps in evidence. Emergency change frequency is often underestimated: each emergency change needs safeguards at the time and a review and approval afterwards, so frequent emergencies multiply effort. Before accepting a quote, ask for the assumed counts of systems, changes per month and emergency changes, and confirm them against your own inventory.

What must be in place before an assessment

An assessor will not accept a change process that exists only in practice. The controls below must be written down, operating, and recorded before anyone reviews them, because each one produces the evidence that shows Article 17 of Delegated Regulation (EU) 2024/1774 is working.

A written change policy with a named owner

The change management procedure must be documented and approved by the management body or a senior owner who is accountable for ICT risk. Confirm the policy states which changes are in scope (software, hardware, firmware, systems and security parameters), how risk drives the level of review, and when the policy was last reviewed. An undated or unsigned draft will not show that the procedure governs real work.

A change record system with mandatory fields

Every change needs one record that captures its purpose, scope, timeline, expected outcome, fall-back and abort steps, test plan, and impact on existing security measures. Ticketing tools such as GLPI's Assistance module can enforce these fields and track each change from request to verification. Check that a sample of closed changes contains every field, not just the ones that were easy to fill in.

An approval matrix that enforces separation

Article 17 requires that the people who approve a change are separate from those who request and implement it. Build a matrix that maps change types and risk levels to approver roles, and configure the tool so an implementer cannot approve their own ticket. Check the audit trail for self-approvals, shared accounts and approvals recorded after deployment.

Tested fall-back plans for critical changes

Changes affecting critical or important functions need a tested route back to the previous state. The fall-back and abort procedure should be written into the change record before approval, with the controlled test results and quality assurance sign-off attached. Ask for evidence of at least one rollback exercise or a documented rollback that was executed in production, and confirm who decided to invoke it.

An emergency change path with after-the-fact review

Urgent fixes sometimes cannot wait for the full approval cycle, so the procedure needs a separate path with its own safeguards. Each emergency change must be logged when it is made, reviewed, and formally approved after implementation. Check that the emergency route has a defined trigger, a named approver, and a deadline for the retrospective review, and that overdue reviews are visible to management.

A sampling-ready evidence archive

Assessors usually test changes by selecting a sample and asking for the full chain of evidence. Store each record with its approval, test results, implementation and verification entries, and any stress-test output for significant changes in a retrievable location. Run a retrieval test by picking random changes from the last reporting period and confirming that the complete file can be produced within a short, agreed time.

Frequently asked questions about DORA change management

Does DORA certify change management?

No. DORA sets no certification scheme for change management or any other control. Competent authorities supervise compliance using their powers under Article 50, and the only authority-issued attestation the Regulation provides for is the one that a threat-led penetration test met the requirements under Article 26(7). Your change management procedure is judged on whether it meets Article 17 of Delegated Regulation (EU) 2024/1774 and whether your evidence shows it operating in practice. If a vendor offers a "DORA certified change process," ask which body issued it, because no such certificate exists under the Regulation.

Can we run DORA change management in-house?

Yes. The organization owns its change management procedure, and nothing in the Regulation requires an outside firm to write or run it. The harder requirement is separation of duties: the people who approve changes must be different from those who request and implement them, so a small team may need documented delegation or compensating review arrangements. Outside help usually goes to tooling setup, documentation templates, or a readiness review before a supervisor or auditor looks at the records. Confirm your own staffing against the separation requirement before you decide.

How much effort does DORA change management take, and what drives it?

No public fact in this brief supplies a cost or duration, so treat any number you hear as unverified until a quote states its basis. The main drivers are how many systems support critical or important functions, how many changes you already make each month, whether your records live in a ticketing tool or spreadsheets, and how much retrospective evidence you must rebuild. One-time work includes writing the procedure, configuring the change workflow, and training approvers. Recurring work includes reviewing changes, keeping security impact assessments current, and recording emergency change reviews. Ask any provider for a written scope listing systems, change volumes, tooling and deliverables, because that scope is what determines the price.

Do small financial entities get a simplified route under the proportionality principle?

Article 4 of DORA applies the proportionality principle, so the depth of your ICT risk management should match your size, risk profile and the nature and complexity of your services. That principle applies to the whole framework, and the RTS requirements are not waived for small entities. Smaller firms can usually document a lighter procedure, with fewer approval layers and simpler impact assessments, provided the core elements remain: every change is recorded, assessed for security impact, tested, approved, implemented and verified, and emergency changes are reviewed afterwards. Confirm with your competent authority how it reads proportionality for your entity type, because the answer depends on your classification.

Does an ICT provider have to follow the same change rules?

Your ICT third-party providers are not bound by your internal procedure, but DORA requires you to manage the risk they introduce. In practice, your contracts and due diligence should require providers to notify you of changes that affect services supporting your critical or important functions, and to describe their own testing and rollback approach. Where a provider deploys changes into a system you rely on, you should be able to see the change record, the security assessment and any emergency change review that affects you. Check the exact contractual terms and provider obligations with your legal and third-party risk teams, because they vary by contract.

What will the assessor ask for first?

Assessors usually start with the written procedure and then ask for a sample of real changes, so the first request is for the change management policy and a list of changes in a defined period. For each sampled change, expect to be asked for the request, the documented purpose, scope, timeline and expected outcome, the fall-back and abort plan, test results, the security impact assessment, and the separate approver's sign-off. They will also ask for emergency change records with their post-implementation review. Preparing a clean sample of these records before the review is usually more effective than writing new policies. Confirm the assessor's sampling approach in advance, since it is set by the assessor, not by the organization.

When to bring in outside help and what to ask for

An implementation partner adds the most value when the change process has to be built or rebuilt across many systems on a tight timeline. Article 17 of Delegated Regulation (EU) 2024/1774 asks for more than a ticket queue: every change to software, hardware, firmware, systems or security parameters needs a documented purpose, scope, timeline and expected outcome, a fall-back and abort procedure, named testing and quality assurance roles, and an assessment of its effect on existing security measures. If your organization has no change tooling, has change records spread across email and spreadsheets, or has never tested a rollback, a partner can configure a ticketing and change workflow, map it to the Article 17 fields, and write the procedure around it. Internal teams can usually handle the same work when a mature change board already records most of these fields and the gaps are narrow, such as adding approver separation or emergency change review.

When you request a quote, ask for a fixed written scope that names the systems in scope, the change types covered (standard, normal and emergency), and the roles that approve, implement and test. Ask for a list of deliverables with the evidence each one produces: for example, a change procedure, a configured workflow with approver and implementer roles that cannot overlap, a template showing the documented fields, a sample of closed changes with fall-back plans and post-implementation reviews, and a record of emergency changes approved after the fact. Also ask who signs off each deliverable on your side, usually the head of IT operations and the information security function, and whether the management body receives the reporting that Article 15 of the same regulation requires for projects affecting critical or important functions.

An independent assessor must still review the controls. DORA sets no certification scheme, and the partner that configured your change process cannot judge whether it works in practice. Your competent authority supervises compliance, and any external review you commission should be carried out by an independent party that did not design the process. Before you sign, confirm with your own compliance and legal advisers which reviewer your supervisor expects and how the findings will be recorded. Plan for the reviewer to sample real changes from your records, so the evidence must exist in your tooling from the first day of operation, not be reconstructed afterwards.

How DeployOpen prepares change management evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the change management tooling and records that DORA ICT change management requirements call for. We prepare the systems, procedures and evidence; your organization owns the controls and an independent auditor or competent authority assesses them.

How we scope

Engagements are fixed-scope, with the change management process, systems and deliverables agreed in writing before work starts.
The written scope names which platforms, change types and approval roles are covered, including emergency change handling.
We confirm with you which systems support critical or important functions, since those set the depth of testing and reporting.

How we build

We configure a change workflow where requests, approvals and implementation are recorded as separate steps with separate owners.
Each change record captures purpose, scope, timeline, expected outcome, fall-back and abort steps, and impact on existing security measures.
We set up post-implementation review for emergency changes and stress-test prompts after significant changes where your scope requires them.

How we hand over

You receive the configured change procedure, role matrix and record templates, along with configuration documentation for the tooling.
Deliverables include a walkthrough of sample change records so your staff can show how each control operates.
We document how the evidence is exported and retained, so your assessor can sample changes independently.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
We can review change records and workflow settings periodically, so gaps are found before an assessment rather than during one.
Confirm with us in writing which evidence, reviews and updates a retainer includes before you sign.