GO-ITS 37 Enterprise Incident Management Process

Document history

1. Foreword

Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the IT standards adopted by the Treasury Board Secretariat for use across the government’s IT infrastructure.

These publications support the responsibilities of the Treasury Board Secretariat for coordinating standardization of Information & Information Technology (I&IT) in the Government of Ontario.

In particular, GO-ITS describe where the application of a standard is mandatory and specify any qualifications governing the implementation of standards.

2. Introduction

2.1. Background

The requirement for an all-encompassing Ontario Public Service (OPS) Incident Management standard was predicated by the positioning of all infrastructure service and support within Infrastructure Technology Services (ITS), a new organization within the OPS mandated in 2005 to deliver these types of services to the OPS. The ITS organization was created in 2006 to achieve this goal. Establishment of this goal required an update of the requirements for the GO-ITS Standard for Incident Management based on the situation described above. The result was an updated version of GO-ITS 37 created and approved in July of 2007.

During February 2009, a series of outages to Ontario.ca infrastructure prompted I & IT Executive Management to conduct a review of both Incident and change management processes and procedures. The review identified deficiencies in a number of areas including; procedures, operational process management and behaviour. The review made specific recommendations to address the deficiencies and these recommendations have subsequently been sanctioned by Information Technology Executive Leadership Council (ITELC). Accordingly, the OPS Enterprise IT Service Management Program (OEIP) has updated the enterprise incident management process standard to incorporate the recommendations.

The updated standard redefined certain aspects of the enterprise incident management principles, roles and the associated process model. Updates to GO-ITS 37 included:

• Principles, roles, responsibilities and the high-level process flow required to ensure an enterprise perspective of incident management for the OPS.
• Definition of a major incident protocol at the process standard level
• Incorporation of ITIL® V3 (2007)^{footnote 1[1]} concepts, introduction of a service-based focus for enterprise incident management disciplines and the natural evolution of IT Service Management within the OPS

These standard elements continue to provide a single unified process for enterprise incident management within the OPS. Use of a single process and supporting information will enable OPS-wide management and reporting for the enterprise incident management process through establishment of associated metrics.

In May 2015, the enterprise IT Service Management (ITSM) tool set was upgraded. The upgrade required updates to this document to accommodate changes in terminology and the priority matrix.

From March to June 2016, a comprehensive review was conducted to assess suggested changes to accommodate evolving business and service management processes.

On October 24, 2016, the new Enterprise Service Management (eSM) division was formed within the Office of the Corporate Chief Information Officer (OCCIO).  eSM brought together the Service Management function from I+IT clusters and ITS under a single, new entity in order to:

• Improve internal IT service delivery
• Enable more consistent processes and service levels across the OPS
• Improve efficiencies in the way IT services were delivered

In addition, the evolution of incident management broadened the process scope to include proactive incident management and the incorporation of event management as a key enabler.  From Fiscal Year 2016/2017, GO-ITS 37 was reviewed and updated to reflect the roles for the new division and additional principles for the evolution of incident management.

On October 1, 2018, I&IT moved under the new Ministry of Government and Consumer Services (MGCS).  To further the government mandate to provide simpler, faster and better government services, eSM joined the Infrastructure Technology Division on October 22, 2018.

2.2. Purpose

The goals of the enterprise incident management process are to restore normal service operation as quickly as possible, minimize the adverse impact on business operations and ensure that the best possible levels of service quality and availability are maintained.

This process standard describes best practices to be utilized for incident management. The process design is organizationally agnostic and is not constrained by the status quo. Implementation of the process may require organizational or behavioural transformation.

2.3. Value to the business

The value of incident management includes:

• The ability to detect and resolve incidents, which results in lower downtime to the business, which in turn means higher availability of the service. This means that the business is able to exploit the functionality of the service as designed.
• The ability to align IT activity to real-time business priorities. This is because incident management includes the capability to identify business priorities and dynamically allocate resources as necessary.
• The ability to identify potential improvements to services. This happens as a result of understanding what constitutes an incident and also from being in contact with the activities of business operational staff.
• The Service Desk can, during its handling of incidents, identify additional service or training requirements found in IT or the business.

2.4. Basic concepts

ITIL defines an ‘incident’ as: "An unplanned interruption to an IT service or reduction in the quality of an IT service." Failure of a service component or element item that has not yet impacted service is also considered an incident (e.g., failure of one disk from a mirrored set).

Incident management is the process for dealing with all incidents. This can include;

• failures, questions or queries reported by the users (usually via a telephone call to the service desk)
• anomalies detected by technical staff
• automatically detected errors or conditions reported by event monitoring tools

The Service Desk Agent (SDA) captures the pertinent information and logs, classifies and prioritizes the incident.

The priority of an incident is primarily determined by the impact on the business and the urgency with which a resolution or work-around is needed (as defined in Appendix 6.3). Objective targets for resolving incidents are defined in Service Level Agreements (SLAs). Major incidents, which typically have highest impact and demand quicker resolution, follow the same process as any other incident, but are managed by a separate procedure.

The Service Desk takes advantage of diagnostic scripts to capture and verify information that is required to quickly resolve the incident. In the case where the Service Desk cannot achieve resolution, this information helps in ensuring the incident is assigned to the appropriate tier 2 group for action. The Service Desk Agent often references incident patterns, the known error database and any available knowledge management records to obtain any information that will assist them in attempting to resolve the incident at First Point of Contact (FPOC).

If the incident cannot be resolved at FPOC, the SDA assigns the incident to a group with more specialized skills. (This is known as functional escalation).

Tier 1-n thresholds

Each support tier may be allocated a certain amount of time to resolve the incident, following which the incident must be functionally escalated to a more specialized group. The amount of time allocated to each tier is set so that service restoration occurs within the agreed targets, as defined in the SLA. These allocations may be adjusted from time to time based upon staffing models, experience on supporting the various services and ongoing changes to service specifications and components.

Accessible description of infographic 1

Queues, support groups and functional escalation

The incident management system supports the practice of queues and queue management: each queue represents a view of all incidents assigned to an organization at all levels of priority. This provides a queue manager with an overall perspective of how the incident management process is being executed across all support groups within an organization at any given time. Should a certain part of the organization be experiencing a back log related to incidents in their respective queues, their respective manager may be asked by the queue manager to perform hierarchical escalation, to notify more senior management of the situation in an effort to relieve the pressure on any specific queue.

This basic concept applies to the design of the incident management process within the Ontario Public Service; however, organizational maturity currently prevents the industry best practice from being strictly followed. It is important to note this concept as it describes the desired organizational behaviour or "future-state" model.

Various support groups have also been established in each OPS organization based upon areas of functional expertise. An incident can be assigned to any one of these support groups, where it is then assigned to an individual member of that group to undertake incident diagnosis and resolution. All of these support groups must roll up into an organizational queue view, so that the overall perspective is available to the Queue Manager.

A Service Desk Agent, who cannot resolve an incident at FPOC, assigns it to the appropriate tier n support group, based upon the initial diagnosis.

Once the Service Desk Agent has assigned the incident to a tier n Incident Analyst, one of three things typically occurs:

• Resolution: The Incident Analyst restores service, sets the incident status to resolved and informs appropriate tier n resources, if required.
• Re-assignment: The Incident Analyst concludes that the cause of the incident does not lie in the support agent’s area of expertise and assigns the incident back to the Service Desk for re-assignment to a more appropriate group
• Functional escalation: The Incident Analyst cannot resolve the incident within defined threshold and requests that the incident be assigned to the support group with more specialized skills

A Queue Manager role is established for an individual support group to monitor their respective queues at regular intervals to identify any incidents that have not been assigned to individuals, or have not been resolved within defined thresholds and to take proactive action.

Accountability

Regardless of the support staff and organization to which an incident may be assigned, the Incident Manager (part of the OPS IT Service Desk [OPS ITSD] organization) remains accountable for ensuring that enterprise incident management process and procedures are followed and that prompt incident resolution activities are undertaken with service level objectives in mind.

Whoever restores service (Service Desk Agent or tier 2-N support group), they are accountable to confirm with the customer and/or end user that service has been restored and verify the accuracy of the resolution categorization prior to resolving the incident. The incident management tool, eSMT, will close the incident fifteen days after the ticket is in a resolved state. The exception is the Major Incident Protocol (MIP) where the Incident Coordinator (IC) is accountable to resolve the incident.

Inputs to the incident management process include ^{footnote 2[2]} :

• Incident records from calls to the Service Desk
• Service level objectives (from SLAs)
• Capacity management thresholds and monitoring alerts
• Incident resolution details from the incident template
• Incident patterns and workarounds from incident knowledge management database
• Known errors from problem management
• Configuration Item (CI) data from configuration management
• Change requests (CRQ)

Outputs from the incident management process include ^{footnote 3[3]} :

• Closed incidents - services restored
• Change Requests (CRQ) - incident resolution
• Inconsistencies found while interrogating the Configuration Management Database (CMDB)
• Consistent, meaningful and maintained incident records
• Meaningful management information

2.5. Scope

2.5.1. In Scope

Incident management includes any event which disrupts, or which could disrupt, a service. This includes events which are communicated directly by users through the Service Desk or events detected through an automated interface from event management to incident management tools.

For purposes of clarity, any use of the terms Incident Manager, incident management or incidents within this document includes the "enterprise" perspective described in Section 2.1.

Service requests do not represent a disruption to agreed service, but are a way of meeting the customer’s needs and may be addressing a specific aspect or feature of the service being provided (request fulfillment). This will be documented in the service level agreement with each customer and the service level objective will be outlined therein. Service requests are dealt with by a separate request fulfilment process.

Service requests in the OPS may be currently tracked under the same incident management enabling technology used by the Service Desk for incident logging.

Incident management scope:

2.6. Applicability statements

2.6.1. Organization

Government of Ontario IT standards and enterprise solutions and services apply (are mandatory) for use by all ministries/clusters and to all former schedule I and IV provincial government agencies under their present classification (Advisory, Regulatory, Adjudicative, Operational Service, Operational Enterprise, Trust or Crown Foundation) according to the current agency classification system.

Additionally, this applies to any other new or existing agencies designated by Management Board of Cabinet as being subject to such publications, i.e., the GO-ITS publications and enterprise solutions and services, and particularly applies to Advisory, Regulatory, and Adjudicative Agencies. Further included is any agency which, under the terms of its Memorandum of Understanding with its responsible Minister, is required to satisfy the mandatory requirements set out in any of the Management Board of Cabinet Directives (cf. Operational Service, Operational Enterprise, Trust, or Crown Foundation Agencies).

As new GO-IT standards are approved, they are deemed mandatory on a go-forward basis. Specifically, in the case of the revised version of GO-ITS 37 V2.0, the effective date has been established as July 1, 2010. Future versions will become mandatory on the effective date established for that version.

When implementing or adopting any Government of Ontario IT standards or IT standards updates, ministries and I&IT clusters must follow their organization's pre-approved policies and practices for ensuring that adequate change control, change management and risk mitigation mechanisms are in place and employed.

For the purposes of this document, any reference to ministries or the government includes applicable agencies.

2.6.2. Requirements levels

Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:

Must: This word, or the terms "required", or "shall”, means that the statement is an absolute mandatory requirement.

Should: This word “should”, or the adjective "recommended”, means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g., business functionality, security, cost) must be understood and carefully considered before deciding to ignore the recommendation.

2.6.3. Compliance requirements

Execution of this process at the operational level requires use of procedures, work instructions and enabling technology to automate certain workflow aspects. These elements will be produced by the organization selected by ITELC as the Operational Process Manager. Pending formalization of an ITSM process lifecycle management protocol, the following statements are presented to ensure that these elements are fully compliant with this standard:

• Procedures must be developed by decomposing each process step from section 4.3 into procedural subtasks. These procedures must be submitted to the Enterprise Process Owner for certification that they comply with the spirit and intent of the process standard.
• Work Instructions must be developed by decomposing all procedural subtasks into further subtasks. These must be then submitted to the Enterprise Process Owner for certification that they comply with the certified process and procedures.
• Functional requirements must be developed for enabling technology that will be used to automate aspects of the work instructions and procedures. Functional requirements must also be submitted to the Enterprise Process Owner for certification that they align with the certified procedures.
• Any subsequent modifications to the procedures, work instructions or enabling technology must be managed via Enterprise Change Management (eCM). They are subject to review and endorsement by the respective working committees for any changes/improvements and annual approval by Service Management Executive Committee (SMX).

3. Standards lifecycle management

3.1. Contact information

Accountable role (standard owner) definition

The individual or committee ultimately accountable for the process of developing this standard. Where a committee owns the standard, the committee Chair is accountable for developing the standard including future updates. There must be exactly one accountable role identified. The accountable person also signs off as the initial approver of the proposed standard before it is submitted for formal endorsement to Architecture Review Board (ARB) and approval by ITELC. (Note: in the OPS this role is normally at the IT executive or manager level)

Accountable role:Chair of Service Management Executive Committee (SMX)

Responsible role definition

The organization(s) responsible for the development of this standard. There may be more than one responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization(s) provides the resource(s) to develop the standard)

Responsible organization(s): Infrastructure Technology Services (ITS), MGCS

Support role definition

The support role is the resource(s) to which the responsibility for actually completing the work and developing the standard has been assigned. If there is more than one support role, the first role identified should be that of the editor – the resource responsible for coordinating the overall effort.

Support role (editor):

Ministry: Ministry of Government and Consumer Services (MGCS)
Division: Infrastructure Technology Services (ITS)
Branch:  Service Management Operations & Process Management Branch

Job Title: Senior Manager
Name:  Arpad Martonosi
Phone: (416) 327-2080
Email: Arpad.Martonosi@ontario.ca

Job Title: Incident Manager
Name:  John Mancuso
Phone: (905) 704-2824
Email: John.Mancuso@Ontario.ca

The above individual will be contacted by the Standards Section once a year, or as required, to discuss and determine potential changes and/or updates to the standard (including version upgrades and/or whether the standard is still relevant and current).

Consulted

Please indicate who was consulted as part of the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups.

(Note: ‘consulted’ means those whose opinions are sought, generally characterized by two-way communications such as workshops):

Informed

Please indicate who was informed during the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups.

(Note: ‘informed’ means those who are kept up-to-date on progress, generally characterized by one-way communication such as presentations):

3.2. Recommended versioning and/or change management

Changes (i.e., all revisions, updates, versioning) to the standard require authorization from the "responsible" organization.

Once a determination has been made by the responsible organization to proceed with changes, the Service Management Operations & Process Management Branch, MGCS, will coordinate and provide assistance with respect to the approvals process.

The approval process for changes to standards will be determined based on the degree and impact of the change. The degree and impact of changes fall into one of two categories:

Minor changes - requiring communication to stakeholders. Changes are noted in the "Document History" section of the standard;

Major changes - requiring a presentation to SMX/ARB for endorsement and ITELC for approval.

Below are guidelines for differentiating between minor and major changes:

Major:

• represents a change to one or more of scope, principles, roles or high-level process flow
• responds to legislative changes

Minor:

• does not impact other standards (e.g., updated glossary information or updated informative or normative reference documentation)

3.3. Publication details

All approved Government of Ontario IT Standards (GO-ITS) are published on the OPS Intranet site. Please indicate below if this standard is also to be published on the public, GO-ITS Internet Site.

4. Technical specification

4.1. Process principles

Principles are established to ensure that the process identifies the desired outcomes or behaviours related to adoption at an enterprise level. They also serve to provide direction for the development of procedures and (as necessary) work instructions that will ensure consistent execution of the process. The absence of well-defined and well-understood principles may result in process execution that is not aligned with the process standard. Process principles for OPS enterprise incident management are listed below.

Principle 1:

A single enterprise incident management process shall be used across the OPS in support of I & IT services.

Rationale:

• A single process eliminates costs and inefficiencies of multiple processes for different services.
• Establishment of a Single Point of Contact (SPOC) OPS IT Service Desk (OPS ITSD) in FY 2006/2007 implied a single incident management process for OPS I & IT incident management.

Implications:

• Legacy incident management related procedures and work instructions must be integrated and aligned to the OPS enterprise incident management process.
• Application support groups must adapt existing procedures and work instructions to comply with the OPS enterprise incident management process.

Principle 2:

Incident classification must identify the service(s) that is/are impacted (from the customer’s perspective).

Rationale:

• OPS service directive.
• Formative OEIP business architecture principle to establish a service focus for ITSM processes.
• Enable implementation of Enterprise Service Agreements Model (eSAM).

Implications:

• IT staff must adopt an end-to-end service perspective for all incidents.
• Service classification requirements must be defined and included in enabling technology.
• Service owners must identify the services/hierarchy.
• A service configuration hierarchy must exist in order to identify impacted services.
• IT staff must be trained in new classification techniques.
• Incident messaging with user/customer must communicate the service that reflects the business impact.

Principle 3:

The OPS ITSD shall be the single entry point into the enterprise incident management process and will have oversight of incidents through their complete lifecycle including: assignment, functional and hierarchical escalation, tracking, communication and closure.

Rationale:

• Single accountability for execution of enterprise incident management process.
• Ability to share topical information within a single group and provide enterprise perspective.
• Ability to cross-reference other incidents and establish incident priority from an enterprise perspective.
• Consistent management and co-ordination of incident resolution.

Implications:

• Effective diagnostic scripts and support models are required to assist in triage of incidents and ensure accurate assignment to the appropriate tier-n resources.
• Service Owners must support the objective assessment of reported incidents and ensure criteria for impact and urgency (used to determine priority) are established and communicated to customers through the service level management process.
• Incident assignments/re-assignments to tier-n support must occur via Service Desk only.

Principle 4:

The OPS ITSD shall act as the single point of contact for all business communication regarding reported incidents.

Rationale:

• Consistent support interface for customers.
• Consistent delivery and coordination of communications to internal staff.
• Reduces duplicative messaging and ensures common perspective is provided to customers and to I & IT Senior Management.
• IT tier 2-n support staff are more productive since they are protected from interruptions and the need to manage communications.

Implications:

• Assistance and incident status information must be available (24/7) from the OPS ITSD throughout the entire lifecycle of the incident.
• OPS ITSD and technical support staff will have to adjust their messaging to describe impacts/status in terminology that is service focused and customer based rather than technical in nature.
• OPS ITSD will distribute all major incident communications (sanctioned by the Major Incident Manager).
• Customers or I & IT clusters must have in place a mechanism to broadly disseminate information provided to them by the OPS ITSD.

Principle 5:

An incident must be logged through the OPS ITSD as a prerequisite for engagement of any tier 2-n support staff, including external service providers.

Rationale:

• The incident record is the source for all incident resolution activities undertaken by any support staff.  Failure to document these activities increases the risk of delayed resolution.

Implications:

• OPS ITSD procedures must identify the minimum level of information required to initiate an incident record and to enable effective investigation and diagnosis.

Principle 6:

Closure of incidents shall be dependent upon validating with either the end user or the customer that service has been restored.

Rationale:

• Obtaining positive confirmation of incident resolution ensures that the customer is satisfied with the service delivered.
• Validation step enhances the image of the IT organization.

Implications:

• Customers will identify an appropriate level of resource to accept the validation request.
• A suitable mechanism must be defined to deal with circumstances when end user(s) cannot be reached for validation within a predefined time period.

Principle 7:

There shall be notification and escalation procedures that ensure consistent, timely incident resolution and communication of progress relative to service level agreements.

Rationale:

• Setting customer expectation for timing of periodic status reports will prevent interruptions caused by requests for status.
• More effective delivery of end-to-end service as IT staff will have a clear understanding of agreed incident service level targets, which will guide appropriate functional and hierarchical escalation.
• Incidents resolved within customer expectations will increase customer satisfaction.

Implications:

• Clear triggers and thresholds must be defined for functional and hierarchical escalation, as well as any periodic status notifications (this implies some form of automation); service level objectives (documented in service level agreements) must be clearly and explicitly defined and linked to these thresholds.
• A single escalation procedure must exist for functional and hierarchical escalation and must be adhered to by all participants in the incident management process.
• A single notification procedure must exist for notification.
• Any unique requirements for service-specific notification thresholds must be documented and managed through the service level management process, and outputs from these situations must be configured within the OPS ITSD enabling technology to support the requirements.
• Templates and scripts are required to ensure consistency of messaging.
• Customer messaging must be tailored to deliver a customer perspective.
• Messaging for the internal service provider community may carry a different level of detail, and this will be managed through local work instructions at the OPS ITSD.

Principle 8:

All incident information, including resolution details, shall be logged in an accessible incident management repository.

Rationale:

• Single source of data for all enterprise incidents ensures consistent view and authoritative source for management of incidents.
• Tracking of progress enables ability to escalate.
• Provides knowledge base to enable:
  • Reduction in Mean Time to Resolve (MTTR) for similar incidents by applying previous workaround.
  • Analysis and identification of problems (by problem management process).
• Audit trail informs reporting (service level management).

Implications:

• Incident management must be supported by an integrated IT support system with a common database for logging all incident and resolution information.
• Incident management and problem management must have access to the same database.
• Validation of accuracy of resolution details must occur before any auto-closure of tickets.

Principle 9:

A separate procedure shall be established to manage resolution of major incidents that will include nomination of a single manager for the incident. This resource will be assigned from a pool of management within ITS, Cyber Security Division or the Cluster.

Rationale:

• Major incidents involve outages where the business impact is high and usually impacts public-facing services.  Restoration justifies extraordinary attention and resources.
• Special leadership may be required to secure and manage resources to ensure prompt resolution of major incidents.  This will include authority to make human resources decisions/financial commitments as required.
• Establishment of an accountable lead will ensure ownership of the major incident and provide an objective point of escalation and contact throughout the life of the incident from declaration to major incident review.

Implications:

• Criteria for major incident declaration must be defined, documented and communicated to stakeholders and then linked to incident prioritization activities at the OPS ITSD.
  • Criteria may vary by service; it is neither reasonable nor efficient to define “one size fits all” criteria that apply to all incidents.
  • It is an expensive undertaking to invoke major incident procedures and secure and coordinate the resources required to deal with a major incident. Therefore, care must be taken to prevent subjective or reactive declaration by specifying objective, quantifiable attributes for an incident to be declared major.
  • Priority 1 incidents are defined as major incidents.
• Ability to engage and receive confirmation of acceptance from the accountable Major Incident Manager must be 24/7.
• Incident Analyst staff in any organization must be contactable on a 24/7 basis to support major incidents.
• Some major incidents may not require special leadership if resolution activities are outside the span of control of the OPS I & IT community (e.g., major power outage or major weather situation across the province).
• Staff involved in the incident management process must be trained in the major incident procedure.
• Logistics, facilities and technical requirements for a situation room must be identified and provisioned to support prolonged or multiple incident events.  This information must be made widely available to all stakeholders in the enterprise incident management process.

Principle 10:

Any proposed service restoration activity which has the potential to impact other services or other customers of the same service must be approved by the Service Owner(s) before being undertaken.

Rationale:

• Ensures that incident resolution activities do not impact other services or other users of the same service.
• Ensures a business perspective is considered before possible disruptive actions are taken for incident resolution.

Implications:

• Service Owner(s) must be contactable 24/7.
• As an alternative to 24/7 availability, a defined policy must be developed by the Service Owner that will outline the proposed approach for each of the services in the catalogue of the Service Provider.  This policy must be shared with stakeholders and embedded in all service level agreements. The Incident Manager or Major Incident Manager (see Principle 9 above) would be contacted to provide requisite approval (after due consideration of the policy).
• An ability to relate components and enabling services is required to understand potential impact to other users.  This information is typically obtained from the Configuration Management Data Base (CMDB).

Principle 11:

Incident resolution activities must commence as soon as possible for all incidents regardless of priority.

Rationale:

• Industry best practice supports determining as soon as possible the extent and effort required to resolve incidents.
• Delaying resolution activities for a seemingly minor or misdiagnosed incident could increase the impact to the customer (activities to resolve incidents reported during non-prime shifts, if deferred to next business day, can result in service-affecting impact to the customer).

Implications:

• Unresolved incidents must be monitored on a periodic basis and their impact reassessed based on service level objectives.
• Local work instructions must prescribe that a “sweeping” of the incident queues be performed on a periodic basis to ensure outstanding incidents have been actioned in support of service level objectives.
• Ability to engage active support of tier 2-n resources outside of business hours.
• Priority 2 incidents that are assigned to tier 2-n support groups outside of regular business hours may not be actioned until next business day.

Principle 12:

All Service Owners and OPS Service Providers shall fulfill their roles in compliance with the OPS enterprise incident management process.

Rationale:

• Consistent participation from all stakeholders is required to ensure success of the enterprise incident management process.

Implications:

• Underpinning Contracts (UCs) with external service providers must reflect the enterprise incident management process requirements.
• Operating Level Agreements (OLAs) between internal service providers must be in place and reflect enterprise incident management process requirements.

Principle 13:

A mechanism must be in place to identify security-related incidents and engage appropriate support staff to resolve the issue.

Rationale:

• Security- related incidents may require specialized skills that are not resident in the OPS ITSD organization.

Implications:

• A security support group must be established and staffed on a 24/7 basis.
• Special procedures must be defined and agreed to by the OPS ITSD and Cyber Security Division (CSD) to address security-related incidents.
• OPS ITSD staff must be provided with initial and ongoing training to ensure they are equipped to identify potential security-related incidents.
• This mechanism must be bidirectional in nature as CSD must have the ability to proactively inform the OPS ITSD of a security-related incident.

Principle 14:

A proactive enterprise incident management process is required where high likelihood of future impact is detected, and corrective action is required to prevent business impact.

Rationale:

• The ability to detect and resolve incidents before business impact occurs results in lower downtime and higher availability of a service.
• The dynamic allocation of resources to address identified business priority prior to impact ensures the best possible levels of service quality.

Implications:

• Event management is a requirement to detect exceptions that may cause business impact.
• Incident management processes can be activated before users contact the OPS IT Service Desk.
• Automation may be applied for the resolution of incidents where appropriate.  For example, a script can be run to automatically restart a service when an event detects that a website has become unavailable.

Principle 15:

Event management is essential to enterprise incident management by providing information on the status of I+IT services and detecting any deviation from normal or expected operational behaviour.

Rationale:

• Provides the ability to identify an exception that can be resolved before the user is impacted or to minimize the impact on the user.
• Enables automated responses, creating efficiencies in timeliness and utilization of resources.

Implications:

• Event management tools are required to interface with the incident management tool.
• Automated responses must be logged within the enterprise Incident Management Tool to enable validation and trending for problem management.
• The appropriate priority will be assigned to the incident created from an event.

Principle 16:

An event transitions to an incident when it is assessed as a clearly defined exception that may cause significant impact to business services.

Rationale:

• A defined process must be applied to highlight significant events and avoid being inundated by insignificant events.
• Human or cognitive analysis is required before the event is transitioned to an incident.  The analysis will include verification of business impact and priority.
• The incident must identify the exception, the significance of the exception and the information required to determine the appropriate action to take.

Implications:

• All events do not require immediate or expedited activities for remediation.
• Events that are manageable through event logs or alert consoles do not require transition to incidents.
• Information is available to quickly and accurately assess impact and urgency.
• Event generated incidents shall have a unique identifier to differentiate them from user generated incidents.
• When there are recurring event-generated incidents, similar to recurring user‑generated incidents, problem management will be engaged to investigate the root cause.

4.2. Process roles and responsibilities

Each process requires specific roles to undertake defined responsibilities for process design, development, execution and management. An organization may choose to assign more than one role to an individual. Similarly, the responsibilities of one role could be mapped to multiple individuals.

One role is accountable for each process activity. With appropriate consideration of the required skills and managerial capability, this person may delegate certain responsibilities to other individuals; however, it is ultimately the job of the person who is accountable to ensure that the “job gets done.”

Regardless of the mapping of responsibilities within an organization, specific roles are necessary for the proper operation and management of the process. This section lists the mandatory roles and responsibilities that must be established to execute the incident management process.

Legend: Responsible, Accountable, Consult before, Informed
A*

• Major Incident Manager is accountable to resolve major incidents per major incident protocol
• Situation Manager may be called upon to resolve other incidents as deemed necessary by the Incident Manager

R** Incident closure is automated by the tool at this time

Enterprise incident management process owner

The Process Owner owns the process and the supporting documentation for the process. The Process Owner provides process leadership to the IT organization by overseeing the process and ensuring that the process is followed by the organization. When the process isn't being followed or isn't working well, the Process Owner is responsible for identifying why and ensuring that required actions are taken to correct the situation. In addition, the Process Owner is responsible for the approval of all proposed changes to the process and development of process improvement plans.

Responsibilities

• Ensures that the process is defined, documented, maintained and communicated at an enterprise level through appropriate vehicles (e.g. Corporate ARB).
• Undertakes periodic review of all ITSM processes from an enterprise perspective and ensures that a methodology of continuous service improvement (including applicable process-level supporting metrics) is in place to address shortcomings and evolving requirements.
• Ensures that all enterprise ITSM processes are considered and managed in an integrated manner, taking into consideration OPS policies and directives and factoring in evolving trends in technology and practice.
• Solicits OPS stakeholders and communities of interest to identify enterprise ITSM process requirements for consideration by the enterprise ITSM program.
• Coordinates, presents and recommends options for the prioritization, development and delivery of process requirements to appropriate governing body.
• Ensures enterprise ITSM procedures and work instructions and functional requirements for enabling technology are aligned with the enterprise process.

Segregation of duties

The role of enterprise Process Owner is separate and distinct from that of the Incident Manager and the roles shall be separately staffed.

Incident Manager (IM)

The Incident Manager is accountable for managing execution of the incident management process and directing the activities of all OPS I&IT organizations required to respond to incidents in compliance with SLAs and SLOs. The Incident Manager is accountable for the lifecycle of all incidents and acts as the incident management point of escalation for incident notification and for hierarchical escalation.

Responsibilities

• Develops and maintains an appropriate level of incident management procedures and/or work instructions to support the needs of the business.
• Ensures that incident management staff are trained and familiar with IM procedures.
• Monitors IT support staff performance of the incident management process; creates and executes action plans when necessary to ensure effective operation and continuous improvement.
• Manages incident resource allocation and workload distribution.
• Invokes the major incident procedure as appropriate.
• Engages upper levels of management as appropriate.
• Ensures that a major incident review is conducted for all major incidents and that recommended action items are completed.
• Provides information for management related to OPS ITSD performance.
• Highlights trends resulting from recurring incidents for review by problem management.
• Monitors performance of the incident management process and identifies process improvements to the enterprise IM Process Owner.

Major Incident Manager (IM)

In certain cases of incidents, a Major Incident Manager may be required to manage resolution activities. The Incident Manager or delegate will make this determination, and as required, will assign a single individual to undertake the MIM role for the service recovery activities related to that incident. The MIM is accountable for taking actions necessary to resolve a major incident and restore service. In all cases a major incident will be classified using urgency/impact definitions documented in Section 6.3 of this standard.  By definition, major incidents will be classified as priority 1 (P1). Activities managed by this individual may cross organizational boundaries. The MIM will be selected from a pool of management staff within ITS, Cyber Security Division or the cluster.

The administrative aspects of the major incident will continue to be managed through the OPS ITSD and the Incident Manager or delegate will continue to perform responsibilities related to incident notification, escalation and communication.  The Incident Manager maintains ownership and accountability for the lifecycle of the incident.  This allows the MIM to fully focus effort and attention upon managing the technical resolution of the incident.

Responsibilities

• Identifies the required members of the resolution team, and requests their participation via the eIM.
• Ensures that a systematic approach is used to evaluate the reported symptoms, impacts and contributing factors of the incident.
• Ensures assignment of key Incident Analyst to develop the optimum plan to restore service or create a workaround.
• Ensures the incident record is maintained.
• Ensures that status messages are provided in the incident record for periodic progress reports based on the major incident notification schedule.
• Undertakes functional escalation based upon predefined thresholds for the service being supported.
• Provides documentation for major incident review report.

Note:  The Situation Manager will assume the role of the MIM for major incidents when the eIM has determined that no MIM is required to manage resolution activities.

Situation Manager (SM)

The Situation Manager is engaged by the Incident Manager to manage escalations of incidents meeting pre-specified criteria (typically a priority 2). The SM is accountable for taking actions necessary to resolve P2 incidents and restore service.

Responsibilities

• Resolve the escalated incident leveraging resources provided by the Incident Manager.
• Identify and lead the required members of the resolution team to develop the plan to restore service or create a workaround.
• Ensure that status messages are provided in the incident record for periodic progress reports based on the Notification Schedule.
• Perform escalation evaluations.
• Coordinate the establishment of resolution teams.
• Function as “point-of-contact” for resolution teams.
• Manage further hierarchical and functional escalations.
• Recommend activating disaster recovery process (as necessary).

Queue Manager (QM)

The Queue Manager monitors the queue to ensure that all incident tickets assigned to various support groups in their organization are promptly actioned and/or escalated within defined thresholds in support of Service Level Agreements/Objectives (SLAs/SLOs). This role is predominantly concerned with the overall performance of resources involved in the incident management process and is defined to establish an objective perspective on how incident management is being undertaken within a specific organization.  As such, there are no specific accountabilities.

Responsibilities

• Address process execution issues encountered by support personnel and ensure that all tickets assigned to a queue are promptly actioned.
• Monitor the incident queues.
• Ensure that all incidents placed in a queue are assigned to the appropriate resource within the queue.
• Monitor all incidents and advise support group members of upcoming and actual service level breaches. (Note: Engaging support group will only occur if a Service Desk Analyst has not already performed this action.)
• Respond to the escalated incidents in a timely and appropriate fashion to minimize the effect of incidents on agreed service levels.
• Follow defined escalation path as defined in the escalation policy.
• May facilitate support resource commitment and allocation.
• Attend incident review meetings as required.
• Participate in process improvement sessions.

Service Desk Manager (SDM)

The SDM is accountable for all aspects of the OPS ITSD.

Responsibilities

• Manages overall Service Desk activities.
• Acts as escalation point for Team Leads.
• Monitors incident volumes and trends to ensure appropriate staffing levels.
• Recommends procedural improvements to the Incident Manager.

Service Desk Team Lead (TL)

The Service Desk Team Lead provides team leadership, coordination, expertise and advice to ensure OPS IT Service Operations daily activities, to achieve approved goals and standards and ensure service level timelines are met.  The TL provides subject matter expertise for Section/Branch planning, problem solving and project management.

Responsibilities

• Ensures currency and effectiveness of diagnostic scripts used to perform incident triage.
• Manages shift schedules to ensure appropriate staffing and skill levels are maintained.
• Acts as escalation point for Service Desk Agents in difficult or controversial situations.
• Arranges staff training and awareness sessions.
• Produces statistics and management reports.
• Undertakes HR activities as required.
• Assists Service Desk Agents when workloads are high or more experience is required.
• Works with ITS Incident Advisors (ITS-IAs) in co-ordinating regular review and continuous improvement sessions involving appropriate staff.

Service Desk Agent (SDA)

The Service Desk Agent provides the single point of contact for customers during the incident lifecycle.

Responsibilities

• Authenticates the caller (user or customer) and captures minimum level of defined contact information.
• Is aware of the level of support to which the individual reporting the incident is entitled.
• Creates an incident record for the new incident or updates the record for existing incidents.
• Classifies the incident.
• Ensure that description of all incident resolution activities is accurately captured in incident records assigned to them. 
• Continually updates incident records with progress/status information to reflect their own activities.
• Attempts incident resolution at first point of contact (tier 1) using diagnostic scripts and knowledge records such as known errors.
• If unable to restore service within predefined threshold, performs functional escalation and assigns incident to the appropriate tier 2 support group.
• Facilitates functional escalation between tier 2 and tier-n support groups and records circumstances in the incident record.
• Informs the Queue and/or Incident Manager of any “non-minor” incidents.
• Keeps the customer or user updated on incident progress based on notification protocol where applicable.
• Obtains user (or customer) concurrence that the support actions provided addressed their needs prior to the Service Desk classifying  the incident as resolved.

Incident Analyst (IA)

Incident Analysts are tier 2-n support group staff in each organization who provide progressively greater technical expertise to resolve incidents that have not been resolved at the previous tier.

Responsibilities

• Responds to assigned incidents within agreed timeframes.
• Diagnoses, develops workarounds and/or attempts to resolve assigned incidents.
• Requests assistance from other tier 2 support areas via the Incident or Queue Manager.
• If unable to resolve, requests functional escalation via the OPS ITSD.
• Keeps the OPS ITSD informed of progress on assigned incidents via incident -enabling technology.
• Updates the incident record and notifies the client as soon as it is known that the expected resolution will not occur within service thresholds.
• When requested by the Queue and/or Incident Manager, provides technical assistance for other tier-n resources.
• When requested by the Queue and/or Incident Manager, provides technical communication/explanation to customers and/or end users.
• Follows defined process for creation of an incident record for all/any activities undertaken related to remedial action for technology or service supported.
• When resolving an incident, reviews and updates the Service+, CI+, Operational Categorization and Resolution Categorization in the incident management tool to reflect the actual failing component that was corrected to restore normal services.

Note: When designated by the Major Incident Manager as the technical lead for a major incident, the Incident Analyst has additional responsibilities:

• Undertake technical leadership of the analysis, diagnosis and develop the subsequent action plan to remediate the major incident.
• Provide periodic updates and status reports to the Major Incident Manager to ensure communication and notification requirements of the incident management process are satisfied.

Service Owner

The Service Owner has responsibilities specific to the enterprise incident management process.  These fall under the broad category of the service support model that is the responsibility of the Service Owner to define and maintain.  Additional responsibilities for the Service Owner in support of the enterprise problem management process can be found in GO-ITS 38.

In order to provide seamless, end-to-end support for incident management for OPS I&IT services, it is necessary to document all aspects of the support model.  I&IT clusters are accountable for the application component of many of the OPS services; the enterprise incident management process must be informed with key aspects of the support structure for applications.

The Service Owner is responsible for the identification, documentation and maintenance of internal/external partner solution/service knowledge required to inform the support model used by the OPS ITSD.

Responsibilities

• Define and establish the support model (including required skills for tier 2-n support staff) up to and including the application.
• Provide information, via the Infrastructure Technology Services Incident Advisor, to the ITSD. This would include items such as service/solution descriptions, diagnostic content, mandatory information capture at Tier 1, and First Point of Contact (FPOC) resolution steps for use by Service Desk Agents.
• Maintain the above information and inform the appropriate parties of updates:
  • Infrastructure Technology Services Incident Advisor for support model updates.
  • Service Level Manager for revisions to service level objectives.
• Develop local procedure information in support of incident management for cluster services/solutions and obtain endorsement from the enterprise Incident Manager that these align with OPS ITSD procedures.
• Accountability and managing of applicable vendors including but not limited to engagement during incidents in a timely manner.

Infrastructure Technology Services Incident Advisor (ITS-IA)

The Infrastructure Technology Services Incident Advisor (ITS-IA) provides a point of contact between the Incident Manager and partner organizations (e.g., DCO, Telecom, clusters, CSD, 3^rd Party Service Providers) to enable effective and efficient execution of the incident management process.

Responsibilities

• Coordinates with Service Owners in their portfolio to provide and maintain support models with the information required by the OPS ITSD (i.e., impact and urgency, Situation Mangers, escalation contacts, support structure, service/solution descriptions, diagnostic approach, mandatory information capture and First Point of Contact (FPOC) resolution steps.
• Provides accurate organization information management relative to incident management process, including VIP lists, location, details, organizational and/or staff changes, etc.
• Delegate of the enterprise Incident Manager in rotational coverage.
• Coordinates incident resolution activities for organizations within the portfolio.  Fulfils the role of Major Incident Manager for the portfolio as required. Has the authority to bring in appropriate executives to make human resource or financial decisions required through a communications protocol.
• Acts as the escalation point for any organizational issues regarding execution of the incident management process.
• Acts as lead on tickets 90 days or older.
• Creates/performs P2 incident reviews.
• Analyzes and reviews reports to identify and highlight incident trending and assist with root cause analysis/problem management for recurring high-impact incidents.  Assist with the transition of incidents to problem investigations.
• Represents the incident management process for portfolio release management activities.
• Attends/participates in MIRs and continues to co-ordinate portfolio-related action items.
• NAS Critical Site List:  Maintenance of portfolio locations and site contacts.
• Assist the Communications Coordinator as required.

Communication Coordinator

The Communication Coordinator is accountable to the Incident Management and Communications Process Owner and performs the day-to-day communications operational tasks demanded by the process activities.  The Communication Coordinator is primarily responsible for communications that provide status updates or information to a targeted audience.

Responsibilities

• Responsible for Executive/Business, Informational and Technical communications to Service Owners, executive, business and cluster audience.
• Promotes and communicates the process to all parties involved.
• Assists with incident management briefing notes if required.
• Participates in situation rooms if required.
• Monitors and performs monthly analysis to determine opportunities for continual service improvement of the communications process.
• Contributes to monthly operational performance reports.
• Collaborates with other communications teams/resources to assist with forecasting potential I+IT impact.  Creates I+IT awareness by appropriate means.

Incident Coordinator

The Incident Coordinator functions as the primary focal point for priority 1 and 2 incidents while in tandem coordinating the process execution, resource identification and Major Incident Review (MIR) activities.

4.3. Process flows

4.3.1. Incident management process overview

Accessible description of infographic 2

4.3.2. Incident management process tasks

4.4. Linkages to other processes

Consistent use of service and component classification schemas must be used across ITSM processes such as incident, change and problem management to enable industry best practice process integration. Failure to adopt a common approach to implementing these three processes will result in needless rework and additional administrative overhead for operational staff.

4.5. Incident management process quality control

Certain aspects of execution of the incident management process are monitored, as a quality control measure, to identify opportunities to improve process effectiveness and efficiency.

Monitoring

The Incident Manager is responsible for monitoring certain aspects of the activities performed by the incident management team on a regular basis. This serves a twofold purpose:

• The Incident Manager can identify any bottlenecks at the operational level and take appropriate corrective action.
• Both the Incident Manager and the enterprise Process Owner can identify opportunities for improvement at the process and procedural levels.

Reporting

Reporting involves measuring the process via metrics and recording how well it behaves in relation to the objectives or targets specified in the metrics. Metrics provide incident management personnel with feedback on the process.  They also provide the incident management Process Owner with the necessary information to review overall process health and to undertake continual service improvement techniques. 

Evaluating

Evaluating the process involves regular reviews of the execution of the process and identification of possible improvements or actions to address performance gaps. Every process is only as good as its last improvement; hence, the feedback loop of continuous improvement is inherent in every process.

4.6. Metrics

Metrics are intended to provide a useful measurement of process effectiveness and efficiency. Metrics are also required for strategic decision support. The following need careful consideration:

• Reporting metrics will be readily measurable (preferably automated collection and presentation of data).
• Metrics will be chosen to reflect process activity (how much work is done), process quality (how well was it done) and process execution (to review and plan the job at hand).
• The enterprise incident management Process Owner is accountable for the definition of an appropriate suite of metrics to determine the overall health of the enterprise incident management process.
• The Incident Manager will develop and run the reports and may develop other metrics to monitor other operational aspects of process execution, such as workload and resource balancing.

The following represents the initial suite of metrics that will be used to analyze process performance, identify opportunities for improvements and for strategic decision support. Any count of incidents must exclude service requests.

Workload:

• Total numbers of incidents per period (as a control measure) (excluding service requests)
• Number and percentage of major incidents
• Size of current incident backlog

Process Effectiveness:

• Number and percentage of incidents reassigned
• Number and percentage of incidents incorrectly classified
• Percentage of incidents resolved within agreed response time

Process Efficiency:

• Percentage of incidents closed by the Service Desk without reference to other levels of support (often referred to as ‘first point of contact’)
• Mean Time to Resolve Incidents (MTTR)
• Percentage of incidents resolved on first attempt
• Percentage of assigned incidents resolved within service level objectives (total and broken down by queue)
• Percentage of event-generated, potential user impacting incidents compared to user reported incidents
• Percentage of incidents resolved prior to user impact
• Aging report showing the number and percentage of assigned incidents per organization that have been outstanding for longer than periods as designated from time to time by the IM Process Owner

4.7. Standard process parameters

For an enterprise process to be effective, parameters used for the classification, categorization, prioritization and closure of incidents must be consistently used across the OPS.  Special attention must be given to parameters required for consistency of reporting. This is particularly important for the provision of reliable business intelligence.

Please refer to the Classification Model section of the GO-ITS 44 ITSM Terminology Reference Model for standard process parameters and allowable values for incident management.

Please refer to the State Model section of the GO-ITS 44 ITSM Terminology Reference Model for standard status/state parameters and their definitions for incident management.

5. Related standards

5.1. Impacts to existing standards

5.2. Impacts to existing environment

6. Appendices

Detailed document history

The complete revision history of GO-ITS 37 is listed below:

6.1. Major Incident Protocol (MIP) Ver. 2.1

The Major Incident Protocol defines the mandatory elements that must be established in order to develop and execute the Major Incident Protocol.

Table of Contents

1  Introduction to Major Incident Protocol
1.1 Background
1.2 Purpose
1.3 Basic Concepts
1.4 Scope
2  Technical Specification
2.1 Criteria for Major Incident Declaration
2.1.1 Criteria for High Impact
2.1.2 Criteria for High Urgency
2.2 Situation Room Requirements
2.3 Escalation Schedule
2.4 Notification Schedule
2.5 Procedural Tasks

1  Introduction to Major Incident Protocol

1.1 Background

During February 2009, a series of outages to Ontario.ca infrastructure prompted I & IT Executive Management to conduct a review ^{footnote 4[4]} of both incident and change management processes and procedures. The review identified deficiencies in a number of areas including; procedures, operational process management and behavior. Specific recommendations were made to address the deficiencies (see Constraints section below), which have subsequently been sanctioned by ITELC (April 2009). One of these recommendations was the development of a common major incident procedure, including establishment of a situation room, for use across OPS I&IT organizations. This document is a normative reference to GO-ITS 37, Enterprise Incident Management Process.

In May 2015, the enterprise IT Service Management (ITSM) tool set was upgraded.  The upgrade required updates to this document to accommodate changes in terminology and the priority matrix.

The Annual IT Rules Work Plan for 2016-17 directed the rescindment of the Normative Reference to GO-ITS 37 and its inclusion as an appendix to GO-ITS 37.

1.2 Purpose

This purpose of this document is to define the mandatory elements that must be established in order to develop and execute a major incident protocol:
•   Mandatory high-level tasks are defined
•   Requirements are defined for establishment of a situation room

The Incident Manager and Major Incident Manager must jointly establish these elements and develop true procedures derived from the mandatory high-level tasks.

1.3 Basic Concepts

Major incidents follow virtually the same steps as normal incidents but with an emphasis on accelerated functional escalation, coordination of resources and enhanced communications management to achieve resolution as quickly as possible.

The Major Incident Protocol (MIP) provides for the dynamic establishment of a separate major incident team under the direct leadership of a Major Incident Manager (MIM). The team is formed on a case-by-case basis to quickly marshal key technical resources to focus on providing the swiftest remedial action to resolve the incident.

Throughout, the OPS ITSD will continue to ensure that all activities are recorded and that users/customers are kept fully informed of progress.

1.4 Scope

It is contrary to best practice to apply the same degree of management overhead required for major incidents to incidents of lesser priority. This document does not preclude the OPS I&IT organization from requesting this Major Incident Protocol (MIP) for incidents of lesser impact or urgency, to be approved at the discretion of the enterprise Incident Manager on a case-by-case basis.

2  Technical Specification

2.1 Criteria for Major Incident Declaration ^{footnote 5[5]}

To be considered for the major incident protocol, an incident must be classified as both high impact and high urgency.

2.1.1 Criteria for High Impact

• A failure of an IT Business Service affecting multiple organizations ^{footnote 6[6]}
• A failure affecting public safety
• A security-related incident affecting a large number of users across multiple organizations where total loss or compromise of critical business data may result
• A core network outage or a network outage affecting a mission critical government location
• A failure affecting > 1000 users
• A failure that affects a money back guarantee public service offering
• Mission-critical applications fully unavailable
• Mission-critical, citizen-facing service degradation causing significant impact (service is unusable by the business or general public)
• Citizen-facing government websites

2.1.2 Criteria for High Urgency

• A formal SLA is in place that specifies an IT restoration of service time of < or = 4.5 hours
• A security threat exists or there is potential for severe or substantial impact
• A failure where formal SLA has been breached or it is known that an SLA will be breached
• Response required includes an immediate and sustained effort using any/all available resources until the incident is resolved
• VIP or Sensitive VIP service interruptions

2.2 Situation Room Requirements

A situation room will normally be used to bring response/resolution teams together.  Typically, this will be facilitated through a conference call set up without an actual physical room.

Physical meeting rooms and locations may be designated for major regional government centers that house I & IT support staff and their managers and must be equipped with the following facilities:

• Speaker-phone
• A permanent standing teleconference bridge with contact numbers maintained and published by the OPS ITSD to all participants in enterprise incident management
• Network access point (and preferably a PC)
• Access to the incident management enabling technology
• Wireless network access (via a separate redundant path)
• Whiteboards and markers

Participants must be familiar with the use of generic, redundant communications (e.g., Blackberry PIN or SMS messages) to allow communication in the event of disruption to the email or telephone systems. The OPS ITSD must maintain and publish a contact list and instructions for this purpose.

Service Owners must establish their delegates and inform the OPS ITSD, who will contact the delegate, should they not be able to contact the Service Owner

2.3 Escalation Schedule

2.4 Notification Schedule

The following represents the default schedule for incident-related communications. The MIM may choose to modify this schedule when the action plan is established.

2.5 Procedural Tasks

The following table outlines the high level tasks required to manage a major incident. They are similar to normal incident management tasks, but with a different emphasis on communications management and expedited resolution.

Legend: SDA = Service Desk Agent, IM = Incident Manager, QM = Queue Manager, MIM = Major Incident Manager, IA = Incident Analyst,
SO = Service Owner, SDM = Service Desk Manager (or Team Lead), IC = Incident Coordinator

6.2. MIP Ver. 2.1 revision history

6.3. Enterprise differentiation: process, procedure, work instruction

Process, procedure and work instructions are three levels of task descriptions that are often confused with one another.

• Level 1 tasks are defined in a process. They specify what action must be taken and who is involved.
• Level 2 tasks are defined in procedures that decompose each level 1 task into more granular operational tasks and additionally, prescribe how the activity should be performed.
• Level 3 tasks represent work instructions. They are further decomposition of procedure-level tasks that typically are defined to address any unique local requirements when performing a procedural task.

6.4. Definitions: urgency and impact

The following table provides the framework for classifying the urgency and impact of incidents, which are then used to establish incident priority. Urgency and impact were originally defined in GO-ITS 44 Terminology Reference Model, to ensure that local process implementations used common terminology.

ITSM has matured across the OPS and enterprise processes are now in place for incident, problem, change management and service and asset configuration management. The definitions have been updated to reflect best practices.

7. Glossary

Description

Infographic 1: Functional escalation process flow

Process flow chart demonstrating the functional escalation steps for each support tier.

• Step 1, the Incident is logged and classified with Tier 1, which is the IT Service Desk.
• Step 2, the IT Service Desk provides initial support.
• Step 3, if the issue is resolved the incident is closed. If the incident cannot be resolved at Tier 1 it moves to Tier 2 support for investigation and remediation.
• Step 4, if the issue is resolved the incident is closed. If the incident cannot be resolved at Tier 2 it moves to Tier 3 support for investigation and remediation.
• Step 5, if the issue is resolved the incident is closed. If the incident cannot be resolved at Tier 3 it moves to Tier N support etc.

Infographic 2: Enterprise incident management process overview

Process flow demonstrating the enterprise incident management process steps.

• Step 1, User reports the incident to the Service Desk.
• Step 2, Service desk analyst will log and classify the incident.
• Step 3, Service desk analyst will prioritize the incident.
• Step 4, Service desk analyst will determine whether or not it is a major incident.
• Step 5, if not a major incident, the service desk analyst conducts the Tier 1 diagnosis. If it is a major incident, the major incident manager engages the major incident protocol.
• Step 6, if the incident can be resolved the incident is closed. If not, the service desk analyst performs a functional escalation to Tier 2.
• Step 7, the subsequent support tiers will conduct diagnosis until the incident is resolved.