Top ITIL Interview Questions & Answers (2026)

First, confirm it's major against our criteria: many users affected, a critical service down, or a possible security angle. Then declare it, raise the major incident record and get the right resolver groups on a bridge. Roles are set from the start: a major incident manager coordinating, technical leads diagnosing, and a communications owner updating users and stakeholders at a fixed interval, even when the update is 'no change yet'. The focus is restoring service, through a workaround or rollback if needed, before root cause. Once restored, we confirm with users, close the incident and open a problem record so a post-incident review finds the cause and tracks actions.

A standard change is low risk, well understood, fully documented and pre-authorized, like adding memory to a virtual machine with a tested procedure, so it doesn't need fresh approval each time. A normal change has to be assessed and authorized by the right change authority, which depends on risk and impact: a peer or team lead for low risk, a change advisory board or senior leaders for high risk. An emergency change must be implemented as soon as possible, often to resolve an incident, so it gets expedited assessment, possibly by a separate, smaller authority, but it's still recorded and reviewed afterwards. ITIL 4 calls this change enablement because the goal is speed with controlled risk.

The value chain has six activities: plan, improve, engage, design and transition, obtain or build, and deliver and support. For me it's a reminder that value never comes from one team. Take a new remote access service: engage is talking to users and the business, design and transition is building and releasing it safely, obtain or build is buying licenses and configuring the platform, and deliver and support is the service desk handling the first wave of calls. When things go wrong it's usually at the joins, such as the service desk not knowing a release went out. Thinking in value streams across those activities helps me spot those gaps.

I prioritize on impact and urgency, not the label the user picked. Impact is how many people or how critical a business function is affected; urgency is how quickly that impact grows or matters. A trading desk that can't place trades is high on both, while one person's printer is low on both even if it's marked urgent. Most organizations have a priority matrix built from those two, so I apply it consistently and note my reasoning. I also look for patterns, because ten similar tickets may be one incident. If priorities are routinely inflated, I raise it with the service owner, since the categories or targets may be encouraging people to game them.

I'd start with questions rather than dashboards: where do users lose the most time, and which services generate the most repeat work? Then the data: top categories by volume and by total handling time, reopen rates, tickets bounced between groups, aging tickets, and incidents linked to recent changes. Repeat incidents become problem candidates. High-volume simple requests become candidates for self-service or automation. Frequent reassignments point to unclear routing or knowledge gaps. I'd check categorization quality first, because bad categories make all of it misleading. Then pick one or two improvements, measure a baseline and track the result, which is the continual improvement model in practice.