Change Request Artefacts: From Raise to Release Under DORA

Change management is the part of operational governance that teams describe as "too heavy" until a change causes an incident, at which point the same teams describe it as "clearly insufficient". The truth is that change management is neither too heavy nor too light in principle; it is adapted or unadapted to the risk of the change. In regulated scope, the adaptation question has been answered partly by the regulator. DORA Article 9 (protection and prevention), Article 12 (backup and recovery), and the broader operational resilience expectations set explicit requirements for how changes to ICT systems must be assessed, approved and evidenced.

This post covers the change request artefact stack as it should work in a DORA-compliant operating environment, from raise through impact assessment and approval to release. The patterns apply across financial services and are informed by the supervisory expectations in the EBA guidelines on ICT risk management and the PRA Supervisory Statement SS1/21 on operational resilience.

Why the artefacts matter

A change request is not the ticket in ServiceNow. It is a collection of artefacts that together demonstrate: the change was considered, the risk was understood, the impact was assessed, the approval was made with appropriate authority, and the release was executed with controls. Under DORA, the firm must be able to produce this collection on demand. Without structured artefacts, the firm is reconstructing the narrative each time, which is expensive and unpersuasive.

The artefacts also matter for operational reality. A change whose impact has been properly assessed has a lower probability of causing an incident. A change whose approval carries appropriate authority has a lower probability of producing surprise at senior level. A change whose release is executed with controls has a lower probability of needing rollback under pressure.

The core artefact stack

Six artefacts make up the core stack for material changes. Smaller changes use a subset.

1. Change request document

The formal raise. What is being changed, why, when, by whom, with what expected outcome. The change request is the authoritative statement of the change scope. Every downstream artefact references it.

A production-grade change request includes:

• The change type (standard, normal, emergency, major) per the firm's change taxonomy
• The systems, processes, and data in scope
• The business justification and expected benefit
• The proposed implementation window
• The risk category and the initial impact assessment
• The referenced supporting artefacts (change impact assessment, test plan, rollback plan)

2. Change impact assessment

The structured assessment of what the change will affect. Systems, processes, data, customers, regulators, third parties. The change impact assessment resource provides a full template; the key point is that the assessment is not a narrative paragraph but a structured evaluation against each impact dimension.

Under DORA, the ICT impact dimension is non-optional. The assessment must answer: which critical or important functions does the change affect, is the change within the impact tolerance for those functions, and what is the operational resilience implication of the change's worst-case outcome.

3. Test plan and test evidence

What testing will be done before release. Functional testing, regression testing, integration testing, performance testing, security testing, resilience testing. The specific tests depend on the change type. For material changes, the test plan references the UAT test script library and includes the specific scripts that apply.

Test evidence is produced during execution and retained with the change record. For regulated changes, evidence must be retained for the period specified in the firm's record retention policy, typically five years or more.

4. Rollback plan

What the firm will do if the change fails. How the rollback is triggered, by whom, on what authority. How long the rollback takes. What data or state is affected. A rollback plan that says "restore from backup" is incomplete; the plan specifies which backup, restored to which state, with what data loss window.

Under DORA, the ability to recover from a failed change within the impact tolerance for the affected function is explicit. Rollback plans that cannot meet the impact tolerance must be escalated.

5. Approval record

Who approved the change, under what authority, at what time, with what conditions. Approval is not a checkbox; it is a decision, and it belongs in the decision log for material changes.

For DORA-scope changes, the approval chain reflects the risk category. High-risk changes require approval at a level commensurate with the impact. A change affecting a critical or important function will typically require CIO-level or CRO-level approval depending on the firm's taxonomy.

6. Release evidence

What happened during and immediately after the release. Implementation start and end times, the individuals who performed each step, any deviations from the plan, the post-implementation verification results, and the status at handover to operations.

Release evidence is the artefact that answers the question "did the change go as expected" and is the first artefact examined when something goes wrong after a release.

Change categories and their artefact expectations

Not every change needs the full stack. The firm's change taxonomy should map change categories to artefact expectations.

Standard changes

Pre-approved, low-risk, repeatable. The artefact expectation is minimal: the ticket, the pre-approved change template, the release record. Examples: user provisioning, patch deployment within approved windows, routine data refresh.

Normal changes

Not pre-approved, but routine. Full artefact stack required, but the depth of each artefact is proportionate to the risk category. A normal change affecting a non-critical function can be lighter than a normal change affecting a critical function.

Major changes

Significant business or technical change. Full artefact stack with additional scrutiny. Impact assessment involves second-line functions. Approval involves senior management. Release often involves a command centre or formal command structure. Post-implementation review is mandatory.

Emergency changes

Response to an immediate incident. Truncated pre-change artefacts; comprehensive post-change artefacts. The rollback plan must be clear before proceeding. A post-implementation review (including a review of why an emergency was required) is mandatory within a defined window.

Under DORA, emergency changes affecting critical or important functions may trigger incident reporting under Article 17 even if the change itself was successful, depending on what the emergency revealed about the firm's risk posture.

The role of change advisory boards

A change advisory board (CAB) is the governance forum that reviews and authorises changes above a certain category. In DORA-regulated scope, the CAB does not rubber-stamp; it scrutinises. The scrutiny questions are structural:

• Is the impact assessment sufficient for the change's risk category?
• Is the test plan adequate to the change's scope?
• Is the rollback plan executable within the impact tolerance?
• Are the affected second-line functions consulted?
• Is the release window chosen to minimise customer and market impact?

A CAB that asks these questions consistently adds value. A CAB that approves by default provides no governance and should be re-designed.

Common failure modes

Failure: the change request without impact assessment

The change is raised with a brief description and approved quickly because the description does not highlight risk. The actual impact is discovered during the release or after. Fix: impact assessment is mandatory for all change categories except standard changes, and the assessment is reviewed by a second pair of eyes before approval.

Failure: the rollback plan that cannot be executed

The rollback plan is "revert to the previous version" without detail. On the night of the release, the team discovers the database schema change is not reversible without a full restore, which takes six hours. Fix: rollback plans are tested before the change is approved. Changes whose rollback cannot be verified do not proceed.

Failure: the approval without authority

The change was approved by someone without the authority for that risk category. When the change causes an incident, the accountability is unclear. Under SMCR, this is an exposure for the SMF whose domain was affected. Fix: the firm's change taxonomy explicitly states the approval authority by change category, and the approval tooling enforces it.

Failure: the release evidence that disappears

The change was released. The release evidence was stored in a shared drive that was archived. Three years later during an audit, the evidence cannot be found. Fix: release evidence is stored in the authoritative change record, with retention aligned to regulatory requirements.

Failure: the change that bypasses the process

"It was urgent." "It was a quick fix." "The CAB would have approved it anyway." Changes that bypass the process are the source of most avoidable incidents and most supervisory findings. Fix: bypass controls are themselves a control. Emergency changes have an explicit, auditable route. Non-emergency bypasses are treated as control breaches.

Connection to the broader stack

Change request artefacts connect to:

• The RAID log: risks identified in the impact assessment flow to the RAID log.
• The decision log: approval is a decision recorded here.
• The stakeholder register: impact assessment identifies affected stakeholders.
• The requirements traceability matrix: changes may affect requirements coverage.
• The DORA third-party register: changes affecting third-party interfaces require third-party notification and sometimes contractual variation.

DORA specific considerations

Under DORA, the change process must demonstrate:

Article 9 (protection and prevention): changes do not introduce vulnerabilities. Security testing is part of the test plan. Threat modelling for material changes.

Article 10 (detection): changes do not impair the firm's ability to detect anomalies. Monitoring coverage is validated post-change.

Article 11 (response and recovery): changes do not impair the firm's response and recovery capability. Resilience testing covers the change.

Article 12 (backup policies): changes to backup and recovery arrangements themselves follow elevated scrutiny.

Article 16 (simplified ICT risk management) for smaller entities has proportionate expectations, but the structural requirement for impact assessment, approval and evidence remains.

The DORA specific scrutiny articles in the supervisory technical standards provide additional detail on the granular expectations.

External references

The EBA guidelines on ICT risk management cover the detailed expectations on change management in regulated financial services. The ITIL 4 change enablement guidance provides a broader framework that can be adapted to regulated scope.

The short version

Change request artefacts are the evidence of change governance. Six core artefacts, calibrated to change category, connected to the broader governance stack, retained as regulatory evidence. Under DORA, this is not optional; it is an operational resilience requirement with specific supervisory expectations.

Firms that invest in the artefact discipline find that audits are straightforward, incidents are rarer, and supervisory confidence is easier to maintain. Firms that treat change management as ticketing ceremony find that the first material incident reveals the gaps in costly fashion.

Our regulatory compliance transformation service and business analysis service include the change artefact discipline as part of the operational governance uplift for DORA-scope firms. For broader DORA context, see our DORA compliance and AI post.