Registration Data Incident Management Policy Author: DCC Operational Policy Draft Version 1 Date: 1 st May 2014 Page 1 of 23
Contents 1 Document History 4 1.1 Document Location 4 1.2 Review Dates 4 1.3 Revision History 4 2 Introduction 5 2.1 Purpose 5 2.2 Scope 5 2.3 Principle 5 3 Overview 6 3.1 Data Transfer and Ownership 6 3.2 Registration Data Incident Types 6 3.2.1 Connection Failure 6 3.2.2 Authentication Failure 7 3.2.3 Authorisation Failure 7 3.2.4 Identification of an Anomaly 7 3.2.5 Validation Failure 7 3.2.6 Other Circumstances 8 3.3 Known Delays 8 4 Registration Data Incident Management 9 4.1 Raising an Incident 9 4.1.1 DCC 9 4.1.2 Registration Data Provider 9 4.1.3 Required Information 9 4.2 Incident Management Log 10 4.3 Incident Categorisation 10 4.3.1 Classification Table 10 Page 2 of 23
4.4 Timetables 11 4.4.1 Electricity Registration Data Provider Obligations 11 4.4.2 Gas Registration Data Provider Obligations 13 4.5 Incident Assignment 13 4.6 Communications 14 4.7 Incident Escalation 14 4.7.1 RDP Notification 14 4.7.2 Escalation process 14 4.8 Major Incident Management 15 4.8.1 DCC Major Incidents 15 4.8.2 Non-DCC Major Incidents 15 4.9 Incident Closure 15 4.10 Reopening Closed Incidents 16 4.10.1 Repeat Incidents 16 4.11 Reporting and Service Measures 16 5 Definitions 17 Page 3 of 23
1 Document History 1.1 Document Location The source of this printed document can be found on DCC Sharepoint. 1.2 Review Dates Date of this Revision Date of Next Review 1 st May 2014 Annually 1.3 Revision History Revision Date Revision Number Changed By Summary of Changes 12 th March 2014 0.1 Nicola Robertson Initial draft 21 st March 2014 0.2 Nicola Robertson Updates post User Forum 28 th March 2014 0.3 Nicola Robertson Updates post peer review 01 st April 2014 0.4 Nicola Robertson Updates post peer review 04 th April 2014 0.5 Jackie Crouch Updated following meeting 07 th April 2014 0.6 Jackie Crouch Updated following internal review 16 th April 2014 0.7 Nicola Robertson Updated post feedback 27 th April 2014 0.8 Nicola Robertson Updated post feedback 29 th April 2014 0.9 Nicola Robertson Updated post feedback 1 st May 2014 0.10 Nicola Robertson Updated post feedback Page 4 of 23
2 Introduction 2.1 Purpose The purpose of this document is to describe the DCC Registration Data Incident Management Policy which is to be adhered to by the DCC and Registration Data Providers to manage any Incidents arising from the exchange of Registration Data. This document describes how Registration Data Incident Management will operate across the DCC Systems demonstrating that from a Registration Data Provider s perspective there is a single process, system and function for both the gas and electricity industry, whilst simultaneously allowing the DCC the ability to log and manage the proactive and reactive detection and resolution of issues. 2.2 Scope The scope of this policy covers Incidents that are related to either data held in the DCC Total Systems or the Registration Data File Transfer between the RDP and DCC. Any issues with Data or transfers between the User and RDP are outside the scope of the DCC Services and this policy. 2.3 Principle This document is subsidiary to the obligations in the [SEC] and is for Registration Data Providers and DCC, all Users will adhere to the Incident Management Policy. Page 5 of 23
3 Overview This section shows at a high level how the Registration Data transfers between the Registration Data Providers and the DCC. Figure 1 - Registration Data Interfaces 3.1 Data Transfer and Ownership The DCC Data Interfaces enable suitably authenticated and appointed RDPs to interface with the DCC Systems. The Gas and Electricity Registration Data Interfaces enable: The RDPs to send to the DCC up to date Registration Data concerning the Metering Points and supply meter points they administer on behalf of the Network Operator (Registration Data). Registration Data is mastered and managed by the appropriate Registration Data Provider. The DCC to send to the relevant RDP updates as to whether a particular Supply Meter Point or Metering Point has a smart meter that participates in DCC Services or not (DCC Status). DCC Status Files are mastered and managed by the DCC. 3.2 Registration Data Incident Types 3.2.1 Connection Failure Connection failures and file transfer failures that occur when the DCC tries to send DCC Status Files to the RDP or when the RDP tries to send Registration Data Files to the DCC shall be handled by trying to reconnect and/or resend the file on 3 further occasions at 5 minute intervals. If the DCC cannot establish a connection with the RDP after the agreed number of retries, the DCC shall raise an Incident in the DCC Service Management System. Page 6 of 23
If the RDP fails to establish a connection with DCC after the agreed number of retries the RDP shall contact the DCC to raise an Incident in the DCC Service Management System for the DCC to resolve. 3.2.2 Authentication Failure If the Transport Authentication fails when the DCC is trying to send a file to the RDP no connection will be established to transmit the data. An entry shall be written to the DCC Security Audit Trail and an Incident shall be raised by the DCC in the DCC Service Management System. If the Transport Authentication fails when the RDP is trying to send a file to the DCC no connection will be established to transmit the data. In this instance the RDP shall contact the DCC to raise an Incident in the DCC Service Management System. If the signature contained in a file fails the Verification Checks, the recipient of the file shall raise a Security Incident in the DCC Service Management System and shall not process the file. 3.2.3 Authorisation Failure Any attempt by a RDP to access any directories other than its own on the FTP server shall result in an entry written to the DCC Security Audit Trail and an Incident shall be raised by the DCC in the DCC Service Management System. Any attempt by the DCC to access any directories other than its own on the FTP server shall result in an entry written to the DCC Security Audit Trail and an Incident shall be raised by the RDP in the DCC Service Management System. 3.2.4 Identification of an Anomaly The schedules for sending and receiving of files between the DCC and the RDP are defined in the respective Gas and Electricity Code of Connection documents. The DCC shall perform Anomaly Detection to ensure that these schedules are adhered to. Any exceptions to the agreed schedules shall result in an Incident being raised by the DCC or RDP in the DCC Service Management System for resolution. Anomaly Detection also includes the identification of non-conformity of files. Where the recipient of a non-conforming file is the DCC they shall raise an Incident in the DCC Service Management System, where the recipient is the RDP they shall contact the DCC to raise an Incident. 3.2.5 Validation Failure There are a number of possible validation errors that could occur during processing of Registration Data Files and DCC Status Files, with a different response file produced for each. These are detailed in the Gas and Electricity Registration Data Interface Specification Documents. Page 7 of 23
Where the failure response is received as a result of an RDP file that has been sent to the DCC, the DCC shall raise an Incident in the DCC Service Management System. Where the failure response is received as a result of a DCC file that has been sent to the RDP, the RDP shall contact the DCC to raise an Incident in the DCC Service Management System. 3.2.6 Other Circumstances In the event of an issue arising that is not covered by the above, and has arisen as a consequence of complying with SEC E2, business processes shall first be reviewed and only if the issue remains outstanding can the DCC or RDP raise an incident in the DCC Service Management System. 3.3 Known Delays In the event that the Registration Data Provider has a known delay to the file transfer they shall inform the DCC so they can manage the situation appropriately. This shall apply to both planned and unplanned delays. In the event that the DCC has a known delay to the file transfer they shall inform the Registration Data Provider so they can manage the situation appropriately. This shall apply to both planned and unplanned delays. Page 8 of 23
4 Registration Data Incident Management 4.1 Raising an Incident All Incidents shall be raised and recorded in the Incident Management Log which forms part of the DCC Service Management System. Incidents can only be logged by: the DCC the Registration Data Provider sending or receiving the file 4.1.1 DCC The DCC shall identify Incidents through: Event Management business as usual operational processes automated Incidents These Incidents shall be logged by the DCC directly in the DCC Service Management System. If the DCC believe that the Incident meets the criteria for a Major Incident they shall engage the Major Incident Manager. 4.1.2 Registration Data Provider RDP s shall provide and maintain DCC with a list of nominated individuals from their organisation who are authorised to log Incidents with the DCC. Having first established that the issue does not reside within the Registration Data Provider s own environment the Registration Data Provider can contact the DCC Service Desk via phone or email to log an Incident in the DCC Service Management System. 4.1.3 Required Information In order to log an Incident in the Incident Management Log the following information shall be provided (as a minimum): Name Organisation Contact details Users incident reference number where available Date and time fault occurred Location Nature of fault Business Impact Results of Users initial Triage and diagnosis Page 9 of 23
4.2 Incident Management Log The Incident Management Log shall hold records of all Incidents raised within the DCC Total Systems. Once logged each Incident shall be allocated a unique reference number and from then on shall be subject to the DCC s Incident Management process with the log containing all updates on the Incident status. The log shall hold the information as detailed in H9.3. 4.3 Incident Categorisation The initial calculation for categorisation shall be automatically assigned based on the data provided by the RDP at the point of logging the Incident. Incidents shall be categorised using pre-defined categories, types and items within the DCC Service Management System. This categorisation assists with assigning the Incident to the correct Resolver Groups to expedite resolution as well as identifying Interested Party s to notify of updates. Incidents shall be automatically prioritised for resolution within the DCC Resolver Group by the Service Management System based on the Categorisation and the time remaining until SLA breach. 4.3.1 Classification Table All Incidents logged in the DCC Service Management System shall be classified and resolved within the DCC targets as set out below, the DCC shall operate 24x7: DCC Priority Level Description DCC Response Time DCC SLA 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 Service Users; causes significant financial loss and/or disruption to the Service 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. 10 minutes 4 hours 20 minutes 24 hours Page 10 of 23
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 Service User. An Incident which, in the reasonable opinion of the DCC has a minor adverse Impact on the activities of the Users An Incident which, in the reasonable opinion of the DCC has minimal Impact to the activities of the User 45 minutes 72 hours 3 hours 5 days 1 day 10 days If the affected RDP believes the Incident has been logged against an incorrect priority their Service Desk Team Leader can escalate to the DCC Service Desk Team Leader. The DCC can change the Priority of an Incident if more information becomes available or if the impact or urgency changes. The Interested Party s shall be provided with details of why it has been changed. 4.4 Timetables Registration Data Providers are nominated and engaged by a Network Operator. As such the DCC has no commercial relationship with the RDP and cannot back off any SLAs. The DCC will measure OLAs to track and report on Incident timelines where the activity that the DCC is dependent on for Incident resolution sits outside the DCC. Where a full set of the Registration Data Provider s Registration Data has been requested each Electricity Network Party and each Gas Network Party shall ensure that its Registration Data Provider shall use all reasonable endeavours (including working outside of normal business hours where reasonably necessary) to provide the DCC with such data as soon as reasonably practicable following such request (and in any event within the shorter of three Working Days or four days [SEC E2.7a] 4.4.1 Electricity Registration Data Provider Obligations Type Quantity Time Full Refresh Full refresh of the data fields to the DCC Within the shorter of three Working Days or four days Selective Refresh A selective data refresh is a submission of a subset of the data to the DCC The files will be submitted within the timelines directed in the MRA Page 11 of 23
Type Quantity Time File re-submission Re-submission of a file that is not received or is corrupt Within 1 Working Day Table 1 - Timetables - Electricity Page 12 of 23
4.4.2 Gas Registration Data Provider Obligations Type Quantity Time Full Refresh Full refresh of the data fields to the DCC Within the shorter of three Working Days or four days Selective Refresh A selective data refresh is a submission of a subset of the data to the DCC Within the shorter of three Working Days or four days File re-submission Re-submission of a file that is not received or is corrupt Within 1 Working Day Table 2 - Timetables - Gas Where omissions or manifest errors are identified in the Registration Data the DCC shall seek to resolve any such omissions or manifest errors. In such circumstances, the DCC will rely upon and use any or all of the Registration Data that existed prior to its receipt of the incremental update that included any such omission or manifest error [SEC E2.12]. 4.5 Incident Assignment All Incidents logged in the DCC Service Management System shall be owned by the DCC and assigned to an appropriate Resolver Group. Resolver Groups could be DCC Operational Teams or the Registration Data Provider. There are scenarios where the DCC shall require activities from the Registration Data Provider in the resolution of the Incident. On these occasions the DCC shall contact the RDP, explain the issue and describe and request that the activity is completed. The RDP shall respond as soon as reasonably practical (within the timeframes above) to the DCC confirming completion. In these instances any DCC metrics will not include the period of time from engagement of the RDP until their Response is received by the DCC. In the event that the incident is raised or escalated at a time which falls outside of the RDP s hours of operation and the DCC Incident Manager deems the incident to be of the appropriately high severity the RDP shall be contacted via their out of hours facility to progress the remedial activities. In the event that the Incident is raised at a time which falls outside of the RDP s hours of operation and the DCC Incident Manager deems the incident to be of the appropriately low severity the incident shall be placed On Hold Page 13 of 23
and the RDP shall be contacted when their business operations commence on the next working day. During any part of the duration of the Incident which falls outside the RDP s hours of operation the DCC shall put the Incident in an On Hold Issues that require resolution outside of operational hours will be managed by the organisations out of hour s process, which shall include details of process for overnight feeds re-runs. There may be occasions where Incidents have been logged and investigated and turn out not to sit within the DCC Systems. If it is agreed that this is the case the RDP shall be contacted and provided with details to enable them to raise and manage the Incident within their own system. The Incident with the DCC Service Management System shall then be closed. 4.6 Communications Throughout the lifecycle of the Incident updates shall be communicated to the RDP and other identified Interested party s. All updates shall be included in the DCC Service Management System and available to the instigating RDP and other identified Interested Party s. In the event of a Major Incident the DCC will provide proactive communications through a mechanism appropriate to the situation to share common communications in a timely manner. 4.7 Incident Escalation The DCC shall adopt Escalation Management to ensure that where appropriate structured management attention and/or additional resources are engaged. 4.7.1 RDP Notification In the event the RDP believes that they have not had an appropriate Response or they are dissatisfied with the progress of the Incident the organisation shall notify the DCC Service Desk. Full details of the escalation will be included in the Incident Management Log. 4.7.2 Escalation process Day to day issues should be managed between the Service Desks and if the appropriate Response is not being received this will be escalated up through the Service Desk Managers. Any service issues will be referred to the DCC Service Manager via the Users Service Manager. If service continues to be poor or there are continuous failures and there are no agreed rectification plans in place then this can be escalated to the Head of Service by the organisation s Head of Service. If the rectification measures do not significantly improve the service, or there are continuous services failures or issues with individuals this can be escalated to the IT Director by the organisation s IT Director. Page 14 of 23
If there is a dispute that cannot be satisfactorily agreed between the party s this can be escalated to the Panel for its determination which shall be final and binding [SEC 9.13] 4.8 Major Incident Management 4.8.1 DCC Major Incidents In the event of an issue being identified within the DCC Total Systems, that in the RDP s opinion can reasonably be interpreted to constitute a Priority 1 Incident, the RDP shall call the DCC Service Desk to log the call. 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 the DCC Major Incident Manager be engaged to progress and resolve the incident and issue associated communications. In the event of a confirmed Major Incident the DCC shall notify all Interested Party s and advise them of the agreed communications channel. In the event that the issue is not initially identified as a Major Incident but after investigations the DCC confirm that the criteria is met the Incident shall be re-classified and the Major Incident Manager shall be engaged to progress the issue to resolution. There may be occasions where Major Incidents have been logged and investigated but turn out not to sit within the DCC Total Systems. On these occasions the appropriate Party shall be contacted and provided with details to enable them to raise and manage the Incident within their own system. On these occasions the DCC Major Incident Manager shall close the DCC Incident and assist the appropriate Party s Major Incident Manager in seeking a Resolution as reasonably requested. On Resolution of the Incident Problem Management shall be engaged and a Problem Record shall be raised to confirm root cause. Major Incident reports shall be produced and distributed in line with [SEC] H9.11 & H9.12. 4.8.2 Non-DCC Major Incidents In the event of a major Incident outside of the DCC Systems the DCC shall provide all reasonable assistance to the RDP responsible for resolving that Incident that the RDP may request and which the DCC acting reasonably can provide. 4.9 Incident Closure Incidents shall be resolved in accordance with Resolution targets set out in the classification matrix. Details of steps taken to resolve the Incident shall be included in the DCC Service Management System and the Incident can be re-categorised if appropriate, set to resolved and the user notified. The RDP shall have 3 days to respond if they do not consider that the issue is resolved. The DCC shall attempt to contact the RDP to confirm closure but if no response is received within this time period the Incident shall be closed. Page 15 of 23
In the event that an RDP requires Subject Matter Expert advice before confirming closure and the Subject Matter Expert is unavailable they shall contact the DCC and request the Closure period be extended. It may be the position that on resolving the Incident and restoring service a Problem Record is raised and passed to the Problem Management team for progression. 4.10 Reopening Closed Incidents Incidents shall only be re-opened when the Incident has been closed with a Workaround. In these cases Problem Management shall be triggered and either a new Problem Record will be raised or the Incident will be related to an existing Problem Record (the remedy Incident record will be set to resolved and will close when the Problem Record closes) An Incident can only be re-opened by the original raiser in the following circumstances: the Workaround fails the Workaround deteriorates to a point that it affects normal business operations 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 RDP for Investigations and confirmation of root cause. 4.10.1 Repeat Incidents 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 DCC Service Management System. 4.11 Reporting and Service Measures The Incident Management Log shall feed into the standard service management reporting process, metrics shall be made available via that process. Trend Analysis shall be performed on the available data and the output shall feed to the Problem Management process. Page 16 of 23
5 Definitions Term Anomaly Business Continuity DCC Data Services DCC Operational Team Security Audit Trail DCC Service Management System DCC Service User System DCC Services DCC Status DCC Status File DCC Systems Device Definition Means, in relation to any System, an activity or event that is not expected to occur in the course of the ordinary operation of that System A process and set of procedures to ensure the continuity of Vital Business Functions in the case of disaster events. Means the DCC Systems together with all Communications Hubs provided by the DCC as part of the Communications Hub Service The DCC resources providing technical support in order to resolve Incidents. Means the record containing details of equipment and system access and log-on requests The DCC provided central Service Management system giving a single integrated view of Service Management across the End-to-end Smart Metering System. Means the Systems used by the User in relation to the Services including the HAN and Meter Means the services provided, or to be provided, by the DCC pursuant to Section H (DCC Services) or Section L (Smart Metering Key Infrastructure), including pursuant to Bilateral Agreements The state of devices as documented in the Inventory A file containing the DCC Status Means the Systems used by the DCC and/or the DCC Service Providers in relation to the Services and/or this Code, including the SM WAN but excluding the Communications Hub Functions. One of the following: (a) an Electricity Smart Meter; (b) a Gas Smart Meter; (c) a Communications Hub Function; (d) a Gas Proxy Function; (e) a Pre-Payment Interface; (f) an Auxiliary Load Control; or (g) any Type 2 Device (e.g. IHD). Page 17 of 23
Electricity Registration Data Interface Specification Escalate (Incident) FTP Full Refresh Gas Registration Data Interface Specification Incident Means the SEC Subsidiary Document of that name set out in Appendix [TBC].to be incorporated into this Code pursuant to Section X5 (Incorporation of Certain Documents into this Code). An activity that obtains additional resources when these are needed to meet Service Level Targets or customer expectations. Escalation may be needed within any IT Service Management process, but is most commonly associated with Incident Management, Problem Management and the management of Customer complaints. There are two types of Escalation, functional escalation and hierarchical escalation. File Transfer Protocol: A protocol used to transfer files between computer systems over TCP/IP networks. The provision of all data held by a Registration Data Provider for a particular Energy Supplier, used to replace the data held by DCC. Will usually be requested following invocation of the Business Continuity process. Means the SEC Subsidiary Document of that name set out in Appendix [TBC].to be incorporated into this Code pursuant to Section X5 (Incorporation of Certain Documents into this Code). Means an event which causes (or may cause) an interruption to (or a reduction in the quality or security of) the Services, as further described in the Incident Management Policy (excluding Incidents that are subject to the Registration Data Incident Management Policy, but not excluding interruptions to the Services that are consequent on such Incidents). Page 18 of 23
Incident Management Log Interested Parties Lifecycle (Incident) Metering Point Metrics (Incident) Network Operator NMC The DCC shall maintain and keep up-to-date an electronic log (the Incident Management Log) that records the following in respect of each Incident: (a) a unique reference number (to be allocated to each Incident that is identified by, or reported to, the DCC); (b) the date and time that the Incident was identified by, or reported to, the DCC; (c) the nature of the Incident and the location at which it occurred; (d) whether the Incident was identified by the DCC, or otherwise the person that reported the Incident to the DCC; (e) the categorisation of the Incident in accordance with the Incident Management Policy; (f) the person to whom the Incident has been allocated for resolution; (g) the course of action to be taken, or taken, to resolve the Incident; (h) the DCC s Good Industry Practice assessment of which Users and/or Services are affected by the Incident; (i) details of any communications with Users in respect of the Incident; (j) comments regarding any mitigating circumstances regarding the Incident; (k) the potential impact of the Incident on the DCC s ability to meet the Target Service Levels; and (l) the current status of the Incident, and (once applicable) the date and time that the Incident was closed. Any of the people or organisations who may be affected by the Incident The end-to-end Lifecycle of an Incident, from initial logging, through investigation and analysis, service recovery, to resolution and closure. Has the meaning given to that expression in the MRA Metrics define what is to be measured and reported to help manage a process or service. An organisation that monitors and maintains the operation of a communications network Network Management Centre Page 19 of 23
OLA On Hold (Incident) Priority Matrix (Incident) Problem Problem Management Problem Record RDP Operational Level Agreement. A document that defines and agrees the responsibilities and obligations of internal support teams needed to meet the requirements of the service. An Incident is placed 'On Hold' in the Service Management System when awaiting a Response from the User. This has the effect of pausing the Service Level clock. The Priority Matrix enables an appropriate priority to be assigned to each Incident based on the Impact of an Incident to the organisation and the Urgency by which the Incident needs to be resolved. The higher the Impact and Urgency, the higher the Priority. A Problem is the unknown underlying Root Cause of one of more Incidents. The process that undertakes the management of Problem investigation and resolution related activities, both reactively and proactively. A record created and managed within the Service Management System which records all relevant information and manages the Problem resolution process. Means: (a) in respect of each Electricity Distributor, the person nominated in writing to the DCC from time to time by that Electricity Distributor; or (b) in respect of each Gas Transporter, the person nominated in writing to the DCC from time to time by that Gas Transporter, on the basis that more than one Party may specify the same Registration Data Provider, and that the Electricity Distributor or the Gas Transporter shall be deemed to have so nominated itself in the absence of any other nomination Page 20 of 23
RDP System Registration Data Registration Data File Registration Data File Transfer Registration Data Provider Means any Systems: (a) which are operated by or on behalf of an Electricity Distributor or Gas Transporter responsible for providing (or procuring the provision of) Registration Data in respect of a particular MPAN or MPRN; and (b) which are used wholly or partly for the collection, storage, Back-Up, processing or communication of that Registration Data prior to, or for the purposes of, its provision to the DCC over the Registration Data Interface. Has the meaning given to that expression in Section E1 (Reliance on Registration Data). Data file containing updates from the Registration Data Providers. Process for delivering Registration Data File Means: (a) in respect of each Electricity Distributor, the person nominated in writing to the DCC from time to time by that Electricity Distributor; or (b) in respect of each Gas Transporter, the person nominated in writing to the DCC from time to time by that Gas Transporter, on the basis that more than one Party may specify the same Registration Data Provider, and that the Electricity Distributor or the Gas Transporter shall be deemed to have so nominated itself in the absence of any other nomination Resolver Team / Resolver Group Response (Incident) Response Time (Incident) Root Cause The resources providing technical support in order to resolve Incidents. The time taken between an Incident being logged in the Service Management System, and a support resource acknowledging and starting to work on resolving the Incident. This Response time is subject to agreed timescales dependent upon the priority assigned to the Incident. Has the meaning given to that expression in Section H3.20 (Target Response Times) or L8 (SMKI Performance Standards and Demand Management). The underlying reason that an Incident occurred. Page 21 of 23
Security Incident Selective Refresh Service Audit Trail Service Continuity Management Service Desk Service Level means, in relation to any System, any event which results, or was capable of resulting, in that System being Compromised to a material extent. The provision of a selection of data held by a Registration Data Provider for a particular Energy Supplier, used to replace the data held by DCC. This could be due to errors in the daily update that require correcting prior to the next daily update. Means the record of all service activity, including details of Service Requests and Service Responses, Proactive process which seeks to ensure the correct level of protection is applied to each service and system. It also provides on-going management for existing services by undertaking regular reviews of test plans and the level of protection offered in line with changing business requirements. Has the meaning given to that expression in Section H8.1819 (Service Desk). Means, in respect of each Performance Measure: (a) the number of occasions during the Performance Measurement Period on which the DCC performed the activity that is the subject of the Performance Measure in accordance with the Service Level Requirements; expressed as a percentage of (b) the number of occasions during the Performance Measurement Period on which the DCC performed the activity that is the subject of the Performance Measure; provided that the DCC may establish the Service Level for a Performance Measure in accordance with the Performance Measurement Methodology. Service Provider Service Target (Incident) Means an External Service Provider, as defined in the DCC Licence (but always excluding the DCC itself). The agreed time in which certain activities such as Response to, or Resolution of an Incident should be completed. Page 22 of 23
SLA Subject Matter Expert Supply Meter Point Transport Authentication Trend Analysis User Service Level Agreement. This is the agreed definition of how all service components should be delivered, including timescales, service quality and availability. A person with expert knowledge in a particular subject area. Is the point at which the meter measuring a customers consumption is located Ensures secure message transmission An activity undertaken by Problem Management whereby information relating to the resolution of multiple similar Incidents is analysed to identify common traits in order to help with identification of the underlying Root Cause. Means a Party that has completed the User Entry Process (and, in respect of Services available in accordance with this Code to Users acting only in one or more User Roles, a Party that has completed the User Entry Process for that User Role). Verification Checks Workaround (Incident) When a Registration Data File is received by DCC, it undergoes Verification Checks to ensure that it conforms to the correct format, is confirmed as a valid file from the provider, and is not corrupted. Once it is verified, the data is integrated into the main Registration Data database. If the underlying Root Cause of an Incident is not known and cannot therefore be fixed, it may be possible to create a 'Workaround' that allows the User to use the service, albeit maybe not in the usual manner. This would ideally be a temporary solution until a permanent fix is identified and implemented. Page 23 of 23