ITIL 4 IM flashcards
ITIL 4 IM · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Incident definition
- An unplanned interruption to a service or a reduction in the quality of a service. It is the observable event that incident management responds to and restores.
- Incident management purpose
- To minimize the negative impact of incidents by restoring normal service operation as quickly as possible. Normal operation is defined by agreed service levels.
- Major incident
- An incident with significant business impact that requires a separate, escalated response, often with a dedicated major incident team and frequent stakeholder communication.
- Workaround
- A temporary solution that reduces or eliminates the impact of an incident for which a full resolution is not yet available, allowing service to be restored.
- Known error
- A problem that has been analyzed but not yet resolved. It typically has a documented root cause and workaround, stored in the known error database.
- Incident versus problem
- An incident is the observable event or service interruption; a problem is the underlying cause, or potential cause, of one or more incidents.
- Incident versus service request
- An incident is a failure or degradation of service; a service request is a normal, planned user request such as access or information, handled by service request management.
- Impact and urgency
- Impact is the measure of the effect on business processes and users; urgency is how quickly resolution is needed. Priority is derived from both.
- Incident owner
- The role accountable for managing the lifecycle of a specific incident, including coordination, communication, and closure, through to restoration of service.
- Major incident manager
- The role accountable for the major incident process, coordinating technical teams and communicating with stakeholders during a major incident until service is restored.
- Service desk first line
- The first point of contact that logs incidents, performs initial diagnosis, resolves known errors using workarounds, and escalates when it cannot resolve.
- Functional escalation
- Moving an incident to a team or level with more skill, knowledge, or authority to resolve it, such as from first-line to second-line support.
- Hierarchical escalation
- Raising an incident to higher management for decisions on priority, resources, or communication, often used for major incidents or SLA breaches.
- Problem manager
- The role accountable for problem management, including root cause analysis, known error management, and reducing recurring incidents in collaboration with incident management.
- Incident value stream
- The sequence of activities from detecting and recording an incident through classification, diagnosis, resolution or workaround, recovery, and closure, with communication throughout.
- Incident logging
- Capturing an incident as soon as it is detected with enough information to classify, prioritize, and route it to the appropriate support team.
- Incident classification
- Assigning a category, impact, urgency, and priority to an incident so it can be routed, escalated, and reported consistently against service level targets.
- Priority derivation rule
- Priority is a function of impact and urgency, commonly via a matrix. Higher impact and urgency produce higher priority and shorter resolution targets.
- Initial diagnosis
- Checking for known errors and documented workarounds, applying a workaround if available, and gathering symptoms to decide whether to resolve or escalate.
- Escalation decision rule
- Escalate when the current support level cannot resolve within its target time, when impact increases, or when more authority or resources are needed.
- Resolution and recovery
- Applying the fix or workaround, verifying that the service is restored to agreed levels, and confirming with the user before the incident is closed.
- Incident closure
- Confirming user satisfaction, recording the resolution, and closing the incident. Recurring incidents should be linked to a problem record for root cause analysis.
- Post-incident review
- A review after a significant incident that captures lessons, contributing factors, and improvement actions, feeding problem management and continual improvement.
- Incident record fields
- Standard fields include ID, time logged, caller, affected service or CI, category, impact, urgency, priority, status, assignment group, resolution, and closure details.
- Incident status values
- Common statuses are new, in progress, on hold (pending user or supplier), resolved, and closed. Status drives reporting and service level clocks.
- SLA clocks
- Response and resolution targets measured from incident start or logging time. Pause rules, such as pending customer, must be defined and applied consistently.
- Known error database
- A repository of known errors with root cause and workaround, used during incident diagnosis to speed restoration and support self-service.
- CMS and CMDB
- The configuration management system and its database link incidents to affected configuration items and services, enabling impact assessment and routing.
- Incident tool integration
- Incident tooling integrates with event monitoring to auto-create incidents, and with service request, problem, and knowledge management for consistent handling.
- Incident metrics
- Measures include volume, backlog, major incidents, SLA attainment, mean time to restore, and first-time-fix rate, used to drive improvement.
- Service value chain
- The set of activities including engage, plan, improve, design and transition, obtain/build, and deliver and support. Incident management primarily supports deliver and support.
- Four dimensions
- Organizations and people, information and technology, partners and suppliers, and value streams and processes. All four apply to incident management design and operation.