Incident Management Policy

Incident Management Policy Author: DCC Date: 9th May 2014 Page 1 of 10

Contents 1 Incident Management Policy 3 1.1 Incident Management Policy General Provisions 3 1.2 Pre-requisites to log an Incident 4 1.3 Logging an Incident 5 1.4 Required Information 5 1.5 Incident Prioritisation & Categorisation 5 1.6 Incident Assignment 6 1.7 Identifying Interested Parties 7 1.8 Communications 7 1.9 Incident Escalation 7 1.10 Escalation Process 8 1.11 DCC Major Incidents 8 1.12 Non-DCC Major Incidents 9 1.13 Majority Security Incidents 9 1.14 Business Continuity/Disaster Recovery Procedures 9 1.15 Incident Closure 9 1.16 Re-opening Closed Incidents 10 1.17 Repeat Incidents 10 Page 2 of 10

1 Incident Management Policy 1.1 Incident Management Policy General Provisions 1.1.1 Only the DCC and Users shall be entitled to raise incidents. 1.1.2 All Incidents shall be raised and recorded in the Incident Management Log in accordance with Section H9.3 and Section 1.5 below 1.1.3 Users shall provide the DCC with and notify them of any changes to nominated individuals from their organisation who are authorised to log Incidents with the DCC. 1.1.4 Incident Management Policy shall be interpreted in accordance with the provisions of Sections H9.1, H9.2, H9.8, H9.9 and H9.10 1.1.5 This document is the Incident Management Policy Subsidiary Document. 1.1.6 Section H9.1(a) requires raising an Incident by recording it in the Incident Management Log; 1.1.7 Section H9.1(b) requires categorisation of Incidents into 5 categories of severity ( Incident Category 1, 2, 3, 4 and 5 respectively, such that Incident Category 1 is the most severe and Incident Category 5 the least); 1.1.8 Section H9.1(c) requires prioritisation of Incidents, and (in those cases where the DCC is responsible for resolving an Incident) the time period within which an Incident in each Incident Category should be resolved (the Target Resolution Time ); 1.1.9 Section H9.1(d) requires allocation of responsibility for Incidents in accordance with Section H9.2; 1.1.10 Section H9.1(e) requires identification of other interested persons who are to be kept informed regarding Incidents; 1.1.11 Section H9.1(f) requires courses of action to be undertaken in seeking to resolve Incidents, including the need to update the Incident Management Log to record activity carried out (or planned to be carried out); 1.1.12 Section H9.1(g) requires (g) rules for the escalation of Incidents; 1.1.13 Section H9.1(h) requires rules for the declaration of a Major Incident, and for the appointment of managers to coordinate resolution of Major Incidents; 1.1.14 Section H9.1(i) requires rules for the closure of a resolved Incident; and 1.1.15 Section H9.1(j) requires rules for reopening closed Incidents. 1.1.16 Section H9.2(a) requires the User which first becomes aware of an Incident that is not yet logged on the Incident Management Log (or, if logged, is incorrectly logged as closed) shall, where such Incident is reasonably capable of being resolved via the Self Service Interface or via a Service Page 3 of 10

Request which that User has the right to send, exercise such rights with a view to resolving the Incident; 1.1.17 Section H9.2(b) requires subject to Section H9.2(a), the DCC shall be responsible for resolving Incidents to the extent they are caused by: (i) the DCC Systems; (ii) the Parse and Correlate Software; or (iii) a Communications Hub and are capable of being resolved via communications over the SM WAN; 1.1.18 Section H9.2(c) requires subject to Section H9.2(a), the Lead Supplier for a Communications Hub shall be responsible for resolving Incidents to the extent they are caused by that Communications Hub and not capable of being resolved via communications over the SM WAN; 1.1.19 Section H9.2(d) requires subject to Section H9.2(a), the Responsible Supplier for a Smart Metering System shall be responsible for resolving Incidents to the extent caused by Devices (other than the Communications Hub) forming part of that Smart Metering System. 1.1.20 Section H9.8 requires where a User identified as responsible for resolution of an Incident considers (or should reasonably have considered) that the Incident constitutes a Major Incident, such User shall notify the DCC of such fact (in accordance with the Incident Management Policy). 1.1.21 Section H9.9 requires where the DCC becomes aware of a Major Incident, the DCC shall notify all Users that are likely to be affected by such Major Incident (in accordance with the Incident Management Policy). 1.1.22 Section H9.10 requires in the event of a Major Incident: (a) the DCC shall provide all reasonable assistance to the User responsible for resolving that Incident as such User may request; and (b) all Users other than the User responsible for resolving that Incident shall provide the responsible User with all reasonable assistance as that User may request, (in each case) in relation to the resolution of that Incident, including as set out in the Incident Management Policy. 1.2 Pre-requisites to log an Incident 1.2.1 Before raising an Incident with the DCC, the User shall: a) establish that the fault does not reside within the HAN or the meter b) confirm that the fault does not sit within their own environment 1.2.2 In accordance with H9.2 and only in the event that 1 and 2 above have been established the User shall: a) check on the Self Service Interface [SSI] to establish whether an Incident has already been raised for the incident and i. in the event that the User can reasonably determine that an Incident has been raised for this issue the User shall tick the Me too button which will register them as an Interested Party ii. in the event that the User cannot determine an existing incident they shall progress to 2 below b) prior to raising an Incident the list of known issues and other information available shall be reviewed on the Self Service Interface and Page 4 of 10

i. take all reasonable steps to follow the guidance as set out in the self-help material including the application of any workarounds as specified in the known issues in accordance with Section H9.2a c) only in the event of the log an incident with the DCC in accordance with Section H9.1(a) 1.3 Logging an Incident 1.3.1 The DCC shall log Incidents in the Incident Management Log as soon as is reasonably practical. 1.3.2 If the DCC reasonably believes that the Incident meets the criteria for a Major Incident (Section H9.8) they shall categorise it appropriately within the Incident Management Log (Section H9.1(a)). 1.3.3 A User can raise Incidents in the following ways: a) via the SSI b) submission of an email to the DCC Service Desk c) phone call to the DCC Service Desk 1.3.4 If the User believes that the Incident meets the criteria for a Major Incident they shall only raise the incident through a call to the DCC Service Desk who shall log the Incident. 1.4 Required Information 1.4.1 In order to log an Incident in the Incident Management Log the following information shall be provided as a minimum: a) Name b) Organisation c) Contact details d) Users Incident reference number (where available) e) Date and time incident occurred f) Location g) Nature of incident h) Business impact i) Results of User s initial triage and diagnosis including references to existing incidents 1.5 Incident Prioritisation & Categorisation 1.5.1 The DCC shall automatically assign a Category based on the data provided by the User or Registration Data Provider at the point of logging the Incident. 1.5.2 Incidents shall be automatically prioritised for resolution based on the categorisation and the time remaining until Target resolution Time breach. Page 5 of 10

Categorisation Matrix Incident Category Description Target Initial Response Time Target Resolution Time 1 An Incident which, in the reasonable opinion of the DCC: prevents a large group of Users from using the DCC Total Systems; has a critical adverse Impact on the activities of the Users; causes significant financial loss and/or disruption to the User; or results in any material loss or corruption of data 2 An Incident which, in the reasonable opinion of the DCC: has a major (but not critical) adverse impact on the activities of the Users but the service is still working at a reduced capacity; or causes financial loss and/or disruption to the Users which is more than trivial but less severe than the significant financial loss described in the definition of a Priority 1 Incident. 3 An Incident which, in the reasonable opinion of the DCC: 4 5 has a major adverse impact on the activities of the User but which can be reduced to a moderate adverse impact due to the availability of a workaround; has a moderate adverse Impact on the activities of the User. An Incident which, in the reasonable opinion of the DCC has a minor adverse Impact on the activities of the User An Incident which, in the reasonable opinion of the DCC has minimal impact to the activities of the User 10 minutes 4 hours 20 minutes 24 hours 45 minutes 72 hours 3 hours 5 days 1 day 10 days 1.5.3 If the User believes the Incident has been logged against or updated to become an incorrect priority they can invoke the escalation process as set out in section 1.9 below. 1.5.4 The DCC may change the priority of an Incident if more information becomes available or if the impact or urgency changes. The interested Parties shall be provided with details of why it has been changed and the log shall be updated. 1.6 Incident Assignment 1.6.1 All Incidents logged in the Incident Management Log shall be owned by the DCC. 1.6.2 The DCC shall assign Incident resolution activities to the appropriate resolver, which maybe the DCC or User. This assignment shall be in line with Section H9.7. The resolver assigned shall perform the steps deemed appropriate in accordance with Section H9.7. Page 6 of 10

1.6.3 Where the DCC require activities from the User to diagnose or confirm resolution of an Incident. The DCC Target Resolution Time measure shall not include the period of time from the engagement of the User until their response is received by the DCC Service Desk. 1.6.4 Where Incidents have been logged and investigated but do not sit within the DCC Total Systems. The appropriate Party shall be contacted and provided with details to enable them to raise and manage the Incident within their own system. 1.7 Identifying Interested Parties 1.7.1 In accordance with Section H8.16c, the DCC shall, to the best of its ability, take all reasonable steps in accordance with good industry practice to identify which Users and/or Services are affected by the Incident. 1.8 Communications 1.8.1 Throughout the lifecycle of the Incident updates shall be communicated to the User, Registration data Provider and other identified Interested Parties, via email, phone call and/or Incident Management Log as DCC deems appropriate. 1.8.2 Any other Party that it is reasonable to consider would benefit from notification shall be informed as appropriate. 1.9 Incident Escalation 1.9.1 Users and Registration Data Providers shall provide the DCC with and notify them of any changes to a list of nominated individuals from their organisation who are authorised to act in the roles as described in this Incident Escalation section. 1.9.2 The DCC shall adopt Escalation Management to ensure that where appropriate structured management attention and/or additional resources are engaged. 1.9.3 Incidents shall be monitored throughout their lifecycle and automated notifications shall be sent to appropriate resolvers based on classification and time remaining to resolve. 1.9.4 Escalation can only be requested by the organisation that raised the Incident or the DCC. 1.9.5 Incidents can be escalated under the following circumstances: a) disagree with Categorisation b) resolution time about to breach c) lack of appropriate response d) dissatisfied with the progress of an assigned activity e) dissatisfied with the progress of an Incident 1.9.6 Full details of the escalation shall be included in the Incident Management Log by the DCC. Page 7 of 10

1.10 Escalation Process 1.10.1 Day to day Incident escalations shall be managed between the Service Desks 1.10.2 If the appropriate response is not received the issue can be escalated up through the Service Desk Managers. 1.10.3 Only if an Incident is still not getting the appropriate focus or is likely to fail the target resolution time can the User or Registration Data Provider escalate to the DCC Service Manager via their Service Manager or nominated individual. The Service Managers shall agree a rectification plan. 1.10.4 If the agreed rectification steps have not been completed the Incident can be escalated to the Head of Service by the organisation s Head of Service. 1.10.5 If there is an escalation that cannot be satisfactorily agreed between the Parties the Incident can be escalated to the Panel for its determination which shall be final and binding in accordance with Section 9.13. The DCC and escalating organisation shall exhaust all escalation options above before escalation to the Panel and provide appropriate evidence that this has been undertaken. 1.11 DCC Major Incidents 1.11.1 The DCC Service Desk shall perform initial triage on the issue and only if the issue meets or is projected to meet the criteria for a Priority 1 Incident shall Major Incident Management be engaged to progress and resolve the incident. 1.11.2 In the event that the issue is not initially identified as a Major Incident but after investigations the DCC confirm that the criteria has been met the Incident shall be re-classified as a Major Incident. 1.11.3 On resolution of the Major Incident, Problem Management shall be engaged and a Problem Record shall be raised to confirm root cause. 1.11.4 The appropriate details from the Problem Record shall be available for review on the Self Service Interface. 1.11.5 Major Incident reports shall be produced and distributed in line with Sections H9.11 & H9.12. 1.11.6 Where Major Incidents have been logged and investigated but then turn out not to sit within the DCC Total Systems. The appropriate Party shall be contacted and provided with details to enable them to raise and manage the Incident within their own system. 1.11.7 The DCC shall close the DCC Incident and assist the appropriate Parties Major Incident Manager in seeking a resolution as reasonably requested by the Party and agreed to by the DCC. Page 8 of 10

1.12 Non-DCC Major Incidents 1.12.1 In the event of a Major Incident outside of the DCC Total Systems the DCC shall provide reasonable assistance to the Party responsible for resolving the Incident, that the User may request and which the DCC acting reasonably can provide, in accordance with Section 9.10a. 1.12.2 Where Major Incidents occur outside of the scope of DCC Total Services the DCC can act as a central point of communication if requested by the User and where the DCC agrees it is appropriate. 1.12.3 Where action is required by the meter manufacturers the Energy Suppliers impacted shall be expected to lead the investigation and the Incident shall not be managed by the DCC. 1.13 Majority Security Incidents 1.13.1 In the event of an issue being identified within the DCC Total Systems that, in the Users opinion can reasonably be interpreted to constitute a Major Security Incident, the user shall call the DCC Service Desk to log the call. 1.13.2 The DCC Service Desk shall perform initial triage on the issue and only if the issue meets the criteria for a Major Security Incident shall the DCC Security Team be engaged. 1.13.3 In the event that the issue isn t initially identified as a Major Security Incident but after Investigations the DCC confirm that the criteria has been met the Incident shall be re-classified and the Security Team shall be engaged. 1.13.4 In accordance with Section G5 the User shall notify the DCC in the following circumstances: a) they have a Security Incident within their environment of which the DCC needs to be informed b) any security issue that is identified in SEC as requiring notification to the DCC or the Panel (Sections G2.1-2.9) c) Security Incidents that breach the Code of Connection 1.13.5 The DCC shall notify the appropriate Parties as defined in Section G5 as they deem appropriate: a) any security issue that is identified in SEC as requiring notification to the User or the Panel b) Security Incidents that breach the Code of Connection 1.14 Business Continuity/Disaster Recovery Procedures [This section will be consulted on at a later date once the Service Management System, technical designs and BCDR plans are finalised] 1.15 Incident Closure 1.15.1 Incidents shall be resolved in accordance with the resolution targets set out in the Categorisation matrix. 1.15.2 Details of all steps taken to resolve the Incident shall be included in the Incident Management Log. Page 9 of 10

1.15.3 The DCC shall notify the User or Registration Data Provider automatically via email when the Incident is set to resolved. 1.15.4 If the Incident is resolved through the application of a workaround the DCC shall either raise a Problem Record or the Incident shall be related to an existing Problem Record. 1.15.5 The User shall respond to the DCC Service Desk within 3 days if they do not consider that the issue is resolved. 1.15.6 In the event that a User requires Subject Matter Expert advice before confirming closure and the Subject Matter Expert is unavailable the User shall contact the DCC and request the closure period be extended. 1.15.7 In the event of the Incident being related to an intermittent issue the DCC shall apply what they reasonably deem to be an appropriate closure period based on the frequency of the occurrences. 1.15.8 It can be the position that on resolving the Incident and restoring service a Problem Record may be raised and linked to the Incident. 1.16 Re-opening Closed Incidents 1.16.1 Incidents can only be re-opened when the Incident has been closed with a workaround. 1.16.2 An Incident can only be re-opened by the original raiser in the following circumstances: a) the workaround fails b) the workaround deteriorates to a point that it affects normal business operations 1.16.3 If the linked problem record has been closed it shall not be possible to reopen the Incident. On these occasions a new Incident shall be raised by the User for investigation and confirmation of root cause. 1.17 Repeat Incidents 1.17.1 Any recurrence of a previous Incident after closure of the original Incident in line with the closure criteria in this policy shall require a new Incident to be logged within the Incident Management Log. Page 10 of 10