The Change Management module tracks ICT changes through a controlled lifecycle, from the moment a change is raised to its testing, approval, implementation and post-implementation review. It gives you a single, auditable record for each change: who asked for it, which systems and functions it touches, whether a third party is involved, how it was risk-assessed and tested, who approved it, and how it can be rolled back if something goes wrong.
Why change management matters under DORA
Uncontrolled changes are one of the most common causes of ICT incidents at financial entities. DORA (Regulation (EU) 2022/2554) expects you to manage ICT changes through a documented process that assesses risk, tests before deployment, records approvals, and plans for rollback, with proportionate rigour for emergency changes. This module turns that expectation into a structured record you can show an auditor or supervisor: each change carries evidence of the assessment, testing and sign-off that took place, and links to the assets and business functions it affected.
The change list
The main page lists all change requests, newest first. Each row shows:
| Column | Description |
|---|---|
| Ref | The human reference, e.g. CHG-0001. It is assigned automatically and is unique within your organization. Click it to open the record. |
| Title | A short name describing the change. |
| Status | The current lifecycle stage. |
| Type | Standard or emergency. |
| Risk | The recorded risk level (low, medium or high). |
| Raised | The date the change was raised. |
References run CHG-0001, CHG-0002 and so on. The number is allocated per organization when you first save the record, so your team always has a stable identifier to quote in tickets, emails and board packs.
Creating a change
Click New change. The form is divided into four sections: Details, Scope and impact, Testing and approval, and Rollback and post-implementation. Only the title is mandatory, so you can capture a change quickly and fill in the rest as the work progresses. Click Create change request to save.
Details
| Field | Type | Description |
|---|---|---|
| Title | Text input | A concise name for the change. Required |
| Date raised | Date | When the change was requested. |
| Change type | Select | Standard for planned, pre-assessed changes; Emergency for urgent changes made to restore service or close an acute risk. Marking a change as emergency signals that it followed the expedited path and should be reviewed after the fact. |
| Environment | Select | On-Prem or SaaS, to record where the affected system runs. |
| Status | Select | The lifecycle stage. You set it manually as the change moves along: draft, submitted, approved, scheduled, in progress, implemented. |
| Requested by | Type + list | The branch or department that asked for the change. See below. |
| Change owner | Type + list | The branch or department accountable for delivering the change. See below. |
| Description | Textarea | What is changing and why. |
Requested by and change owner: branch or department
Both the Requested by and Change owner fields work the same way. First choose a type, Branch or Department, then pick the specific one from the matching list:
- Branches are drawn from your DORA Register of Information. Use a branch when the requester or owner is a legal entity or branch on the register.
- Departments are your Settings › Groups. Use a department when the requester or owner is an internal team such as Payments, IT Operations or Information Security.
Only the type you select is stored, so a change is attributed to a branch or to a department, never both. If the department or branch you want is not in the list, add it first: departments must exist as a Group in Settings › Groups, and branches must be present in the Register of Information.
Scope and impact
| Field | Type | Description |
|---|---|---|
| Assets affected | Checkboxes | Select one or more ICT assets from your asset register that this change touches. This links the change to the systems it affects. |
| Affects a critical or important function | Checkbox | Tick this when the change touches a function you have classified as critical or important. DORA applies heightened expectations to changes affecting these functions. |
| Third-party involved | Checkbox | Tick this if an ICT third-party provider is involved. It reveals a Third-party provider picker listing your registered providers. |
| Risk assessment performed | Checkbox | Confirms a risk assessment was carried out for the change. |
| Risk level | Select | The assessed level: Low, Medium or High. |
| Security impact assessed | Checkbox | Confirms the change was reviewed for security impact. It reveals a Security impact description field to record what you found. |
Testing and approval
| Field | Type | Description |
|---|---|---|
| Tested in UAT | Checkbox | Confirms the change was tested in a user acceptance environment before deployment. |
| Test results | Textarea | A summary of what testing showed. |
| Approval required | Checkbox | Tick this if the change needs formal approval. It reveals the approving body and approval date fields. |
| Approving | Type + list | The branch or department that signs off the change, chosen the same way as Requested by. To record sign-off by a role such as the CISO, select Department and pick the relevant group. |
| Date of approval | Date | When approval was granted. |
Rollback and post-implementation
| Field | Type | Description |
|---|---|---|
| Rollback plan exists | Checkbox | Confirms there is a documented plan to reverse the change if it fails. Attach the plan itself as a file (see Attachments). |
| Rollback executed | Checkbox | Tick this if the change had to be rolled back. |
| Post-implementation planned date | Date | When you will review the change after it goes live. |
| Post-implementation notes | Textarea | What the review found: did the change work as intended, and were there any follow-ups. |
Attachments
Open a change record and use the Attachments section to upload supporting documents such as the risk assessment, the rollback plan, test evidence or the approval email. Each file lists its size, who uploaded it and when, and you can download or remove it from the same row.
Accepted file types are PDF, DOCX, XLSX, CSV, TXT, PNG and JPEG, up to 25 MB each. Files are encrypted per tenant at rest. Uploading a file requires the change management edit permission.
Editing and deleting a change
Click a change reference to open its record, then Edit to change any field. Updates are saved against the same reference, so the CHG number never changes.
To remove a change, open the record and click Delete. Deletion cannot be undone and is only available to users with the change management Manage permission; users who can only view or edit will not see the button. Anyone with edit rights can create and update changes and upload attachments.
Scenario: an emergency change to core banking
A payment authorization service at a retail bank starts intermittently timing out. The Payments team needs an urgent configuration change to a core banking component. Here is how Nadia, an ICT change lead, records it.
She clicks New change, titles it "Core banking auth timeout hotfix", sets Date raised to today, Change type to Emergency and Environment to On-Prem. She sets Status to submitted.
For Requested by she chooses Department and picks Payments. For Change owner she chooses Department and picks IT Operations, the team delivering the fix.
She ticks the affected core banking asset, ticks Affects a critical or important function, marks Risk assessment performed and sets Risk level to High. No third party is involved, so she leaves that unticked.
She ticks Tested in UAT and notes the result. She ticks Approval required, sets Approving to Department and picks the Information Security group to represent the CISO's sign-off, then sets the Date of approval. She moves Status to approved.
She ticks Rollback plan exists and sets a Post-implementation planned date for the following morning, then saves. The change is now CHG-0007.
She opens CHG-0007 and uploads the rollback plan document and the risk assessment PDF in the Attachments section. After the fix goes live she edits the record, sets Status to implemented, and adds Post-implementation notes confirming the timeouts stopped.
The result is a complete, defensible record of an emergency change: assessed as high risk, tested, approved by Information Security, rolled out with a rollback plan on file, and reviewed afterwards, all traceable under a single reference.