Incident SLA pause conditions

[superkvi]

When a corrective change request is created from an incident, should the incident SLA pause for the whole duration of the change lifecycle?

[Dr Atul G- LNG]

Hi @superkvi 

Wow, what a coincidence! We had the same discussion yesterday, and I completely agree that it depends on the business process. I’ve seen cases where an Incident is raised due to a change, but the change itself could take anywhere from one day to a month to implement. It’s also not necessarily the case that a change is always an emergency.

So, based on my experience, I would recommend not putting a strict dependency or rule around this and instead letting the business process determine the appropriate approach.

[boteeuwen]

The short answer is:
No, the incident SLA should generally not pause for the entire duration of the change lifecycle.
Doing so breaks the purpose of an Incident SLA, which is focused on restoring service to the user as quickly as possible.

An Incident SLA is a commitment to the business or end-user to fix an issue. A Change Request is an internal lifecycle governance process. If a Change takes 3 weeks to get approved and implemented through a CAB (Change Advisory Board), your endd user is left with a broken service for 3 weeks while the Incident SLA sits "paused" showing perfect compliance. This hides structural inefficiencies.

Under ITIL, if an incident requires a structural change to be fixed, you should look for a workaround. Once a workaround is applied, the incident can be Resolved. The permanent fix is then tracked via the Change Request (often linked to a Problem record), completely independent of the Incident SLA clock.