.png?width=250&height=56&name=stonewater-logo%20(1).png)
DSP - Major Incident Management
March 2025 - V2.1
Kevin Blackshaw - Group Head of Service Management
Review Cycle - Annually - Q1
Contents
- Document Control
- Section 1 - Introduction
- Section 2 - What is a Major Incident (MI)?
- Section 3 - Impact and Urgency Matrix
- Section 4 - Examples of a Major Incident
- Section 5 - Why do DSP have Major Incident Management?
- Section 6 - Scope of Major Incident Management (1 of 2)
- Section 6 - Scope of a Major Incident Management (2 of 2)
- Section 7 - Major Incident Management - Outputs
- Section 8 - Customer Communications
- Section 9 - The MIR Report Template
Confidentiality and Copyright
The information contained in this document is confidential and is issued by DSP on the understanding that it will be used only by the staff of, or consultants to, the Client and where consultants are employed, the use of this information is restricted to use in relation to the business. In particular, the contents of this document may not be disclosed in whole or in part to any other party without the prior written consent of DSP © - Database Service Provider Global Limited. All rights reserved.
Validity of Information
DSP has made every effort to ensure that all statements and information contained herein are accurate as per the document release date. Any questions regarding the content of this document should be directed to our Service Delivery Department - ServiceDelivery@dsp-explorer.com
Change Control History
| Version | Date | Update | Owner |
|---|---|---|---|
|
1.0
|
10/10/2022
|
Process live
|
KB
|
|
2.0
|
14/08/2023
|
Internal amendments and review - MIM added value questions added
|
KB
|
|
2.1
|
02/01/2024
|
Section 4.3 – Informing the Account Manager – Added. Section 5.1 Removed. New RCA template added to Document Pack.
|
KB
|
|
2.1
|
18/03/2025
|
No version change as part of annual review - however Major Incident Report (and graphics below) updated to reflect new DSP template
|
KB
|
Document Review
| Reviewers | Date | Update | Owner |
|---|---|---|---|
|
MK/CP/HM/PA
|
23/01/2023
|
SD/CE (Service Management)
|
KB
|
|
KB
|
14/08/2023
|
Ad-Hoc Review undertaken by Group Head of Service Management
|
KB
|
|
KB
|
01/02/2024
|
Annual review of current process undertaken Section 4.3 – Informing the Account Manager – Added. Section 5.1 Removed. New RCA template added to Document Pack.
|
KB
|
|
KB
|
18/03/2025
|
Process reviewed no changes to process. MIR template updated to new DSP format
|
KB
|
Section 1 - Introduction
Welcome to the DSP family, we offer award-winning IT consultancy and managed services for Oracle, Microsoft and Google technologies. We specialise in data platform management, application development, engineered systems and Cloud with a strong presence in Oracle RDBMS, OCI, Exadata, SQL Server, Azure, APEX, and GCP. DSP is a leading technology partner in the UK and has been recognised for that by our technology partners and industry through a wide range of awards and accolades.
As a DSP Managed Services Customer – DSP Offer a range of ITIL based processes to provide Customer Excellence and a standardised our approach to IT Service Management offering. The following document is a brief overview of Problem Management and how the Problem Management Process works at DSP. While offered as a default component of our Managed Service, both Professional Service customers and those customers undergoing Transition (onboarding) can access Problem Management on request via their Account Manager.
Section 2 - What is a Major Incident (MI)?
- A major incident is the highest impact, most urgent type of incident that usually affects a whole organisation or a major part of it.
- Most MIs always result in an organisation’s Production services becoming unavailable and ultimately affect the customer’s financial standing and/or their ability to operate key business functions (such as their ability to trade/make payments).
- Where a customer’s services are impacted a major incident is always escalated with a high degree of transparency and customer visibility - Customer Escalation Process
- There are two ways a major incident can affect an organisation’s services:
1. By preventing customers from accessing the organisation’s services
2. By disrupting employees' ability to complete significant work on time, leading to a business disruption (i.e. payroll/vendor payments). - The above definitions are also applicable to Internal DSP MIs.
- A Major Incident is the highest priority piece of work required by any DSP customer and must take priority over any other activities. DSP Operate a Major Incident Team who are excluded from planned work.
Section 5 - Why Do DSP have Major Incident Management
- To prevent the loss of customers/revenue – Major incidents are highly visible to customers their userbase, customers, shareholders and Snr. Managers.
- To adhere to a generally defined industry standard for the management of business-critical issues
- Quality Control – Professional MSP, consistent and informative
- To have a standard way of working (DSP staff are trained to do the same thing each time to the same standard)
- To improve service availability, learn and reduce re-occurrence – all companies suffer critical outages – the key to good MIMs – is never to suffer the same one again
- To provide a better Customer Experience and invite a higher degree of confidence – DSP are in control even if the fix/root cause is not unknown
Section 6 - Scope of Major Incident Management (1 of 2)
The scope (or coverage) of the Major Incident Process is restricted to –
- Internal DSP Critical Issues
- Customers in MS*
- PROD and DR Environments
*MS / PS / Transition Caveat
The DSP MIM Process is restricted to customers with a Managed Service Contract and who are considered live and in support. Therefore customers being managed by Project Services or Onboarding / Transition Teams cannot access MIM by default. (However, it is possible if DSP Snr Management agree – DSP could use this framework to manage an ad-hoc critical PS or Transition event as an MI - however this would have to be agreed upon formally and DSP would not be required to adhere to SLAs / Service Credits and act on reasonable endeavours)
NB - Presently the full MI Process is being piloted in hours only, and there is no requirement for the Service Delivery Team to extend working hours. However, should a P1 exceed working hours, a reasonable degree of flexibility is expected to help with handover planning overnight.
Before MI (all times)
-
MIM Rota (internal to DSP)
During MI
-
Uniformed P1 messaging
-
P1 Chat
-
Scheduled client meetings
-
Vendor tickets if required
-
Issue Resolution Details
-
Event Timeline (for MIR)
-
Hourly (or Interval Comms) and Final Comms
-
PRB and Change Records
-
Workaround Details if used
After MI
-
Major Incident Report
-
Post Incident Review
-
Tickets confirming follow on changes
All customer interval communications are produced in the same format.
The format (shown on the right) is available from the full MIMs Process document and should be copied and pasted into emails.
The title of Major Incident Communications should be as follows – the comms number should increment by one as each message is sent. The final message should not have a number and end – Final Comms
MIMs Communication Email Title Format
P1 – Major Incident – Customer – Ticket Number – Short Description of Ticket – Comms number
Example of MIMS email communication title
- P1 – Major Incident – DSP – 000001 – Loss of PROD EBS DB – Comms 1
Did you know we do more than Managed Services?
Meet the Customer Excellence Team
At DSP-Explorer, we have a dedicated team to ensure our customers are happy with the service we're providing. If you'd like to meet with the team, get in touch today!