nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Seeking Best Practices for Handling Emergency Changes

Lance Waldrop

We are implementing change management in our environment and seek insights on handling emergency changes. In ITIL, the Emergency Change Advisory Board (ECAB) addresses these requests as a subset of the CAB. Do you prioritize verbal approval before submitting the change request, or is the request submitted first and then handled by the ECAB? Alternatively, do you follow a different process? We are interested in learning about others' practices and experiences.

Accepted answers

Mark Higgins

Hi @Lance Waldrop

We have an ECAB group, or 'Emergency Approval' group.

The change is raised as an Emergency, and an automation rule, takes the ticket straight to Emergency Approval.

One of the ECAB group, are required to Approve the request, which then goes straight to Implementation.

I would recommend that a ticket does need to be raised, which takes minutes, and does need to be approved, before the fix is applied. Auditors tend to see it that way as well . :-)

REgards

Mark

All comments

Jim Knepley - ReleaseTEAM

In my experience, a CAB is most effective when you emphasize the "advisory" part, and don't let it slip to an "approval" board.

For example, if systems are out of bounds for changes because of quarter-end financial reporting, the CAB should be the clearinghouse for that communication and coordination. Teams should want to coordinate their changes with other teams, particularly operations, which the CAB facilitates.

The same goes for ECAB.

So, to your exact question: it depends. IMO, teams should have a good enough grasp on a change that documenting it isn't a burden, but it's fine to backfill the documentation after the incident has passed.

Mark Higgins

Hi @Lance Waldrop

We have an ECAB group, or 'Emergency Approval' group.

The change is raised as an Emergency, and an automation rule, takes the ticket straight to Emergency Approval.

One of the ECAB group, are required to Approve the request, which then goes straight to Implementation.

I would recommend that a ticket does need to be raised, which takes minutes, and does need to be approved, before the fix is applied. Auditors tend to see it that way as well . :-)

REgards

Mark

Lance Waldrop

Hey @Mark Higgins thanks for your input! In your automation rule do you send a notification to your Emergency Approval group via Teams/Slack or some other type of incident management tool? We were discussing establishing a private chat group with our ECAB members who with receive a private message when then emergency RFC was submitted.

Lance Waldrop

Is that recommendation for all situations or just for teams with a mature setup? We are currently in a growth phase, dealing with a lot of monolithic legacy code and lacking formal pipelines. While we're using a similar strategy, our team's focus on resolving issues quickly makes it challenging to ensure complete documentation.

Mark Higgins

hi @Lance Waldrop

We don't do anything other than move to Emergency Approval status, and set the Approvers as the Emergency Approver group, which then sends them a notification via email for them to approve.

We do tend to seperate CAB people from Emergency people, as the Emergency people are normally Heads of IT, or Business, and not the same that sit within the CAB.

You can also state in the approval step, if you need 1 person to approve, or all.

These 'people' are normally trusted, senior IT, do hitting the 'Approval' and moving to 'Implementation' may require discussion, or may be not.

Cheers

Mark

Lance Waldrop

Thanks for your suggestion!

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management