Service Incident Management Procedure

1. Introduction

An incident is an unplanned interruption to a service or a reduction in its quality. This procedure covers every such event that is reported by a user, detected by monitoring or raised by a supplier, from the moment it is noticed until the user confirms that service is restored and the record is closed.

The aim is restoration of service within the agreed time, not diagnosis of the underlying cause. Finding and removing the cause belongs to the Problem Management Procedure; changes needed to restore service follow the Change Management Procedure.

2. Purpose

This procedure ensures that service incidents are recorded once, classified consistently, worked in order of business impact, escalated before targets are breached, and closed only with evidence that service is restored. It gives the service desk, resolver groups and managers one shared set of rules, so that two people handling the same event reach the same priority and the same next step.

3. Objectives

• Restore service within the resolution target for the priority of the incident, for at least [95%] of incidents each month.
• Respond to every incident within the response target, and tell the user who owns it and what happens next.
• Make sure no incident is lost: every contact, alert or supplier notice that affects a service becomes a numbered record.
• Keep users and customers informed at the intervals promised for the priority, without having to ask.
• Give problem management the data it needs: accurate categories, linked configuration items and a clear record of what restored service.
• Keep the share of incidents that are reopened within [7 days] of closure below [5%].

4. Scope

• In scope: incidents on every service in the service catalogue, raised by users, customers, monitoring tools, suppliers or staff, during and outside normal service hours.
• In scope: major incidents, and incidents that are also information security events (these are handled together with the Incident Management Procedure).
• Out of scope: requests for something new or standard (see the Service Request Management Procedure), complaints about the service in general (see the Business Relationship Management Procedure), and planned outages approved through change management.
• Applies to: the service desk, resolver groups, service owners, the supplier manager for supplier-owned resolvers, and every person who reports or works on an incident.

5. Terms and definitions

6. Roles and Responsibilities

7. Incident Management Process

The process runs from detection to closure. Time targets run from the moment the incident is logged unless stated, and are counted in service hours as defined in the service level agreement for the service.

7.1 Inputs and outputs

7.2 Logging

1. Record every contactThe service desk analyst opens an incident for each event within [5 minutes] of receipt, in [the ticketing tool], whatever the channel. Telephone and chat contacts are logged during the contact; emails are logged on first reading. Alerts that open incidents automatically are checked by the analyst within [10 minutes].
2. Search firstBefore creating a new record the analyst searches for open incidents on the same service and configuration item. A duplicate is linked to the parent record rather than worked separately.
3. Capture the mandatory fieldsThe record must hold the fields in Annexure A before it can be assigned: reporter, contact route, service, configuration item, symptom, time of onset, business effect, number of users affected, category and priority.
4. Confirm with the userThe analyst gives the user the incident number, the priority and the next update time, in the user's channel, within [15 minutes] of logging.

7.3 Categorisation

Categories let the process route the incident to the right team and let problem management see where failures cluster. The analyst chooses a category and sub-category from the list below, and may change it when diagnosis shows the first choice was wrong. A record may not be closed with a category of Other.

7.4 Prioritisation

Priority is set from impact and urgency. The analyst sets impact from what the incident affects, and urgency from how soon the business is harmed. The analyst does not set priority from the seniority of the caller; a manager who disagrees uses the escalation route in section 7.9.

7.5 Response and resolution targets

The service level agreement for a service may set tighter targets, and those prevail. Response means a named person has taken ownership and contacted the user. When the clock is paused because the incident waits on the user or on a change window, the reason and the resume condition must be written in the record; pausing for any other reason is not permitted.

7.6 Initial diagnosis and first-line resolution

1. DiagnoseThe analyst follows the knowledge article for the symptom, or the diagnostic script for the service, and tries to restore service within [20 minutes] for P3 and P4 and [10 minutes] for P1 and P2 before escalating.
2. Apply a workaroundWhere service can be restored by a documented workaround, the analyst applies it, records it, and links the incident to the known error if one exists.
3. Resolve or pass onIf the analyst cannot restore service in the time allowed, the incident is escalated functionally. The analyst never leaves an incident unassigned or assigned to an individual who is away.

7.7 Investigation and resolution by resolver groups

1. Accept ownershipThe resolver group accepts the assignment within the response target for the priority, or returns it with a reason. A rejected incident goes back to the analyst, who reassigns it; it does not wait in a queue.
2. Work and recordThe resolver adds each action and finding to the record as it is taken, with time and name, not afterwards. Changes to configuration items are made under the Change Management Procedure; an emergency change is raised where service cannot wait.
3. Restore and verifyThe resolver tests that the service works from the user's side, not only from the system side, and records the evidence.
4. Record the resolutionThe resolver records what restored service, in words a later reader can follow, selects a resolution code, and links any problem record or change record raised.

7.8 Functional escalation

Functional escalation moves an incident to a team with deeper skill. It happens when first-line diagnosis fails within the time allowed, when the incident needs access the analyst does not have, or when the same symptom appears on a number of configuration items.

7.9 Hierarchical escalation

Hierarchical escalation informs managers so that decisions, resources or customer contact can be arranged. It is triggered by time or by impact, and is automatic: nobody needs to ask permission to escalate.

7.10 Major incidents

A major incident is declared when one or more of the following criteria is met. The decision is taken by the process manager or, outside service hours, by the on-call duty manager, and recorded with the time.

• A critical service is unavailable or seriously degraded for [more than 25%] of users or for any customer with a contractual commitment.
• A P1 incident has not been restored within [2 hours], or the cause is not understood.
• There is a confirmed or suspected loss, corruption or exposure of customer data.
• A regulatory, legal or reputational consequence is likely, or the media or a regulator has made contact.
• The service owner or process manager judges that coordinated response is needed.

1. DeclareThe process manager declares the major incident, assigns a major incident manager, and opens a dedicated communication channel and a bridge call within [15 minutes].
2. MobiliseThe major incident manager calls out the technical lead, the communications lead, a scribe and the resolver groups from the call-out list, and agrees the first update time.
3. StabiliseThe team prioritises restoring service over finding the cause. Workarounds, failover and rollback are preferred to new fixes, and any change goes through an emergency change approval.
4. InformThe communications lead issues updates every [30 minutes] to the distribution list in section 7.12, covering what is known, what is being done, who is affected and the time of the next update.
5. ResolveThe major incident manager declares service restored when the user-facing checks pass, and agrees monitoring for [2 hours] before standing the team down.
6. ReviewA post-incident review is held within [5 business days]. It produces a report with timeline, cause as far as known, what worked, what did not and owned actions. A problem record is opened for each unresolved cause.

7.11 Information security incidents

An incident that may be a security event (suspected malware, unauthorised access, data exposure, or loss of a device) is also raised under the Incident Management Procedure and the Information Security Incident Management Policy. The service desk analyst passes the record to security operations within [15 minutes] and does not attempt eradication or deletion of evidence. The CERT-In Directions of 28 April 2022 require cyber incidents to be reported within 6 hours of noticing, and the Organisation keeps ICT logs for 180 days within Indian jurisdiction [confirm the current requirement]. Security operations decides whether a report is due and who makes it.

7.12 Communication

Users and customers are told what is happening in plain words, at the intervals promised for the priority. Updates are written in the incident record and sent through the channel the user chose.

Wording, status page rules and approvals follow the Communication Procedure. No cause is stated to customers until it is confirmed.

7.13 Resolution, closure and user confirmation

1. Propose closureWhen the resolver records the resolution, the incident moves to Resolved and the analyst asks the user to confirm that service is restored.
2. Wait for confirmationThe user has [3 business days] to reply. If the user confirms, or does not reply after two reminders, the analyst closes the incident. If the user says service is not restored, the incident is reopened and the clock resumes at the original priority.
3. Check the recordBefore closing, the analyst checks that category, configuration item, resolution code, resolution notes, and any linked change, problem or knowledge record are present. The process manager samples [10%] of closed incidents each week.
4. Capture knowledgeWhere the incident had no matching knowledge article, the resolver drafts one within [5 business days]. Articles are approved by the resolver group lead.

7.14 Process flow

1. Event detected by a user, monitoring tool or supplier.
2. Service desk analyst searches for a duplicate, logs the incident and sets category and priority.
3. Analyst attempts first-line diagnosis and applies a workaround or fix where one exists.
4. If not restored in time, analyst escalates functionally and assigns to the resolver group.
5. If a major incident criterion is met, the process manager declares a major incident and the major incident steps apply.
6. Resolver group diagnoses, restores service, tests from the user's side and records the resolution.
7. Hierarchical escalation is triggered automatically when time or impact thresholds are reached.
8. Analyst asks the user to confirm, then closes the record after confirmation or the waiting period.
9. Process manager reviews trends monthly; recurring or unexplained incidents are passed to problem management.

8. Interfaces with Other Processes

9. Key Performance Indicators

10. Records and Evidence

Annexure A: Incident record

Annexure B: Major incident report

Annexure C: Incident escalation log

Annexure: Document history

11. Exception

Exceptions to this document are allowed only where compliance is not practicable and the risk has been assessed. A request must state what is to be excepted, why, the risk it creates, the compensating controls, and an end date no later than [6 months]. It is approved in writing by the document owner and the risk owner, recorded in the exceptions register, and reviewed at the end date. An exception does not change the document.

12. Enforcement

Compliance is monitored through internal audits, management review and routine checks by the document owner. Non-compliance is reported through the incident or non-conformity process and handled under the organisation's disciplinary procedure, and under the terms of any contract for people who are not employees. Serious or repeated non-compliance may lead to loss of access and, where the law is broken, to referral to the authorities.

13. Review

This document is reviewed at least every [12 months], and when there is a significant change to the organisation, its systems, its risks or the law, or after an incident that shows it was not effective. Each review is recorded in the revision history.

ISO/IEC 20000-1:2018 references

Related documents

• Service Operating Model
• Problem Management Procedure
• Service Level Management Procedure
• Change Management Procedure
• Incident Management Procedure
• Information Security Incident Management Policy
• Communication Procedure
• Configuration and Asset Management Procedure