Who Approves an Emergency IT Change in the UK?

Last Updated: November 8, 2026

Quick Summary

An emergency IT change is approved by the duty change manager for low-risk, single-system work, and by the Emergency Change Advisory Board (ECAB) for high-risk or cross-service changes. The requester never approves their own change. Emergency it change approval must be recorded in the change system, with a risk score and rollback criteria.

• Low-risk, single-system changes are approved by the duty change manager.

• High-risk or cross-service changes go to the ECAB, with a senior IT leader.

• Critical security or regulatory changes also need the information security lead.

• The requester can never approve their own emergency change.

• Post-implementation review should happen within five working days.

Ready to govern emergency change?ChangeGate records every emergency IT change with approvals and audit-ready evidence.Book a ChangeGate Demo

What Counts as an Emergency IT Change

An emergency IT change is a change that must go live quickly to restore a service, close a serious security gap, or prevent a major outage. It skips the normal planning window because waiting would cause more harm than the change itself. Most teams define this in their change policy, so the test is written down before the pressure arrives, and any emergency it change approval follows that written test.

Emergency versus urgent versus normal change

These three terms get mixed up, and the mix-up causes real problems in approvals. Each one has a different path through the change process.

• Normal change: Planned in advance, reviewed at the usual change advisory meeting, and scheduled into a maintenance window.

• Urgent change: Needed soon, often within days, but not an immediate risk. It can still follow a shortened review.

• Emergency change: Needed now, because a live service is down or a security exposure is active.

A common mistake is labelling a change "emergency" because someone wants it done quickly. That shortcut weakens the audit trail. Keep the label for changes where delay causes measurable harm.

Emergency Change Request Template: The Fields That Matter

An emergency change request should be short enough to raise in minutes, but complete enough to survive an audit. Use one template for every emergency change so reviewers know where to look.

Required information in a change request

Every emergency change request should capture these fields:

• Reason for change: The incident or risk being addressed, with a reference number

• Affected service and configuration items: What will be touched and who depends on it

• Proposed change: The exact action, written so a second person could repeat it

• Expected benefit: What improves once the change is live

• Risk and impact estimate: Likely failure modes and the number of users affected

• Rollback plan: How to reverse the change if it goes wrong

• Requester and approver: Two different people, with the requester never approving their own change

The last point matters most for compliance. Changes approved by the person who raised them break segregation of duties.

Emergency Change Risk Assessment in Practice

Risk assessment in an emergency has to be fast. Score the change on three simple factors: likelihood of failure, business impact if it fails, and how many users are affected. For a fuller method with checklists and scoring matrices, read how to perform a change risk assessment. A quick score tells the approver whether to act now, add a control, or escalate.

Emergency Change Process Explained | ECAB, Implementation & Real-Time Scenario

Palni Inc

Rollback and failure-containment criteria

Every emergency change needs clear rollback criteria before it starts. Decide in advance what counts as failure. Typical triggers include:

• Error rates rising above an agreed threshold within 15 minutes

• A dependent service failing its health check

• Data integrity checks failing after the change

• The implementer unable to confirm the expected result

Watch out: teams often agree a rollback plan but never define the trigger. When the change starts to fail, nobody knows whether to keep going, so the outage gets longer. Write the trigger into the request.

Emergency IT Change Approval Process: Step by Step

The approval process should be quick, but never skipped. Here is the sequence we recommend:

1. Raise the emergency change request and link it to the incident.

2. Run the quick risk assessment and assign a risk score.

3. Send the request to the on-call approver or Emergency Change Advisory Board (ECAB) member.

4. The approver confirms, adds conditions, or rejects the change.

5. Implement the change within the approved scope.

6. Confirm the outcome and record the result against the request.

7. Schedule a post-implementation review within five working days.

Approval matrix by risk, urgency and change scope

The approver should depend on the change, not on who shouts loudest. A simple matrix helps:

Approval SLAs and escalation paths

Set response times for each approver level. For example, a duty change manager should respond within 15 minutes, and an ECAB member within 30 minutes. If no one responds, escalate to the next level automatically. Without a timed escalation path, emergency changes stall at night and weekends, which is when they are most needed.

Emergency Change Approval Workflow: Roles and ECAB

Clear roles stop the approval from becoming a group argument. Most emergency workflows need five roles, not four, because security and compliance sign-off is often the step that gets skipped under pressure:

• Requester: Raises the change and owns the request record. The requester never approves their own change.

• Change implementer: Carries out the approved change and reports the outcome. Can be the same person as the requester only if a separate approver signs off.

• Duty change manager: First approver, handles low and medium risk changes, and owns the escalation clock.

• Emergency Change Advisory Board (ECAB): Reviews high and critical changes, usually a small group that can meet or decide by message.

• Information security lead: Signs off on critical changes involving security exposure, personal data, or regulatory obligations.

ECAB works best when it is small and can decide quickly. Three to five people, with access to the right technical knowledge, is typical. Remote approval by message or phone should be allowed, with the decision recorded in the change system. The ECAB chair should be named in the policy, with a named deputy, so there is no ambiguity about who convenes the board at 2am.

Security, privacy and regulatory controls during emergency changes

Emergency changes are where compliance controls are most likely to be bypassed. A short checklist, completed as part of the request, keeps the essential controls visible without slowing the change down:

• Does the change touch personal data, and if so, is the data protection impact assessment still valid or does it need a fast-track review?

• Does the change affect a regulated system, and does the regulator require notification or evidence retention beyond the normal change record?

• Has the information security lead reviewed the change if it alters authentication, access control, encryption, or logging?

• Is the evidence needed for audit captured in the change record, including the approval decision, the risk score, and the rollback criteria?

For regulated environments, the change record should be retained for the period the regulator expects, and the retention rule should be written into the change policy rather than left to individual teams. A common pattern is to treat the emergency change record as part of the incident record, so the two are retained and reviewed together.

Making verbal and remote approvals auditable

Verbal approval is sometimes the only option during a live outage, but it should be the exception, not the default. When it happens, the approver or the requester should record the decision in the change system as soon as the immediate pressure eases, with the channel, the time, and the conditions. The record should be marked as a retrospective entry so the audit trail shows the sequence honestly.

Watch out: a verbal approval that is never written down leaves no evidence that the approval happened.

Rollback ownership and safe stopping conditions

Rollback is a role, not just a plan. Name the person who owns the rollback decision, and give them the authority to stop the change without waiting for the ECAB to reconvene. Safe stopping conditions should be written into the request: error rate thresholds, health-check failures, data integrity checks, and the point at which the implementer cannot confirm the expected result. When a stopping condition is met, the rollback owner calls it, and the change record shows who called it and when.

Emergency Change Examples and Common Mistakes

A typical example: a payment service slows sharply during peak trading. The on-call engineer raises an emergency request to roll back a database configuration, scores it as high risk, and the ECAB approves it in 20 minutes. The rollback restores service, and the post-implementation review confirms the cause.

Common mistakes we see:

• Retrospective paperwork: Raising the request after the change is already live, which weakens the audit trail.

• Overusing the emergency label: When everything is an emergency, the real ones get lost.

• Missing rollback triggers: Teams agree to roll back but never say when.

• Self-approval: The implementer approves their own change to save time.

Auditing Emergency Changes and Measuring Them Afterwards

Review every emergency change after it closes. Check that the request was raised before implementation, that the approver was different from the requester, and that the rollback plan was recorded. Track a few simple measures over time:

• Number of emergency changes per month, compared with normal changes

• Percentage of emergency changes that needed a rollback

• Average time from request to approval

• Percentage of emergency changes with a completed post-implementation review

A rising emergency rate usually points to weak planning upstream, not a sudden run of disasters. Use the data to fix the normal change process.

Set Up Your Emergency Change Workflow in ChangeGate

ChangeGate gives you one governed record for emergency, urgent and normal change, so approvals, risk assessments and audit evidence sit in the same place. You can set up your emergency change workflow in ChangeGate to see how requests, approvals and evidence are handled end to end. Teams can enforce that the requester cannot approve their own change, route requests to the right approver by risk level, and keep a complete trail from request through to review.

If you are replacing emails and spreadsheets for emergency changes, start by mapping your current approval matrix into ChangeGate. Book a demo to see how the workflow fits your team's approval structure and escalation paths.

Frequently Asked Questions

What is an emergency IT change?

An emergency IT change is a change that must be implemented quickly to restore a failed service, fix a live security vulnerability or prevent a severe outage, and cannot wait for the normal change cycle. Because approval time is compressed, emergency changes carry higher risk of failure. Good practice is to keep the request brief but still record what is being changed, why it is urgent, the expected impact, the rollback plan and who approved it. Each emergency change should be reviewed afterwards to confirm it achieved its goal and to capture any lessons learned for the process.

Who should approve an emergency IT change?

Approval normally sits with a named emergency change authority, often the change manager or an Emergency Change Advisory Board (ECAB) made up of a small group of senior IT and business representatives. The approver should understand the business impact and have authority to accept the risk. The person who raises the change should not approve it themselves, as segregation of duties is a core control. Document the approver, the time of approval and any conditions attached.

How do you assess risk during an emergency change?

Assess risk quickly by checking the systems affected, the number of users or customers impacted, the data involved, whether a tested rollback exists and how long recovery would take if the change failed. Score each factor so the approver can see the overall risk level in seconds. Higher-risk changes should require a more senior approver and a documented rollback step before implementation begins. Revisit the assessment after implementation to record whether the predicted impact matched what actually happened.

How can organisations audit emergency IT changes?

Auditors typically look for a complete change record: the request, risk assessment, approval with timestamp, implementation evidence, testing or validation results and a post-implementation review. Keep these records in one system rather than scattered across email and spreadsheets, so every emergency change can be traced end to end. Check periodically that emergency changes are not being used to bypass normal governance.

Add changegate.io as a preferred source on Google →