Incident ManagementProcedure Manual TeliaSonera

The purpose of this document is to lay down the procedure for Incident Management.

2012 Capgemini - All rights reservedProcess Template Version 1.0 Page 55 of 55 Printed copies are current on date of printing only - 06/26/2013Always refer to the electronic version for the current releaseDocument Control0.1 Change HistoryPublished / Revised DateVersion No.AuthorSection / Nature of Change

18th December 20120.1Santosh ChaudhariInitial Draft

21st December 20120.2Santosh ChaudhariOutput of first workshop

0.2 Distribution ListNameRoleRepresenting

Kerstin WennbergBusiness Solution ManagerTelia Sonera

Annelie HasselbladBusiness Solution SpecialistTelia Sonera

Hakan Pohjanen

Business Solution SpecialistTelia Sonera

Amit PaiService ManagerCapgemini India

Bertil VilhelmssonFunctional & Technical ( Herkulas)Capgemini Sweden

Niklas DrewitzIncident ManagerCapgemini Sweden

Anders LindenProduction PlannerCapgemini Sweden

Boris RistovFunctional & Technical (Argus)Capgemini Sweden

Hiten ViraFunctional & Technical (HAR)Capgemini India

0.3 Approval ListNameRoleRepresenting

Kerstin WennbergBusiness Solution ManagerTelia Sonera

Annelie HasselbladBusiness Solution SpecialistTelia Sonera

Hakan Pohjanen

Business Solution SpecialistTelia Sonera

Amit PaiService ManagerCapgemini India

Table of contents1Scope and Objective12References / Definitions13Policies24Process Workflow35Roles and Responsibilities56Procedure67RACI Matrix for the Incident Management118Measurements, Verifications & References128.1SLA Measurements128.2Verification138.3Templates:139Interfaces/References to Other Processes1310Guidelines14

Scope and ObjectiveThe primary objective of the Incident Management process is to restore normal services as soon as possible, and minimize the adverse impact on business operations, thus ensuring that the best Current levels of service quality and availability are maintained. The Incident management process focuses on rapid service restoration. It does not include a detailed root cause analysis of the incident. This document defines the procedural activities on Incident Management to be operated at locations TeliaSonera (Sweden) and Capgemini India.The scope of Incident Management covers sub-processes and related activities for Incident Detection & Recording wherein a Customer Operation/Telia Users identifies an issue and reports it in the Remedy ticketing tool. In case the Originator is not able to log an incident they will call/email to Telia System Support for logging of the Incident Record.Incident Classification & Support wherein the Incident is analyzed regarding its priority, urgency, impact and risk. Based on the classification the incident gets assigned to an appropriate Resolver Group.Incident Investigation & Diagnosis wherein the HAR AM team (Level2 and Level3 support) collect all needed information and, as preparation for the resolution, analyzes the Incident in detail.Incident Resolution & Recovery wherein the resolution is precipitated by resolution team and handed over to the Originator.Incident Closure wherein the Telia System Support (L1 support) close the incident record in the remedy system on accepted solution.References / Definitions The references and definitions used in this process manual are listed as below Herkulas Contract Synopsis ITIL V3: Service Lifecycle Service Operations covering Incident Management AS-IS Processes of Incident Management

AbbreviationDescription

AMApplication Management

CIConfiguration Item

IMIncident Management

ITILInformation Technology Infrastructure Library

KEDBKnown Error Database

KPIKey Performance Indicator

KDBKnowledge Database

OLA Operational Level Agreement

A,B,C,DPriority of the Incidents

SLAService Level Agreement

TermsDefinitions

IncidentIncident means (a) any event that is not part of the standard operation of a service and that causes, or may cause, an interruption to or a reduction in the quality of that service.

Major IncidentIs an Incident classified according to its high impact and urgency as priority A Incident.

ProblemA cause of one or more Incidents. The cause is not usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further investigation.

Incident RecordIncident record means information captured by Telia Telia System Support personnel about an Incident.

Incident Management SystemIs an automated system used to track the status of Incident Records defined and maintained by Telia Telia System Support personnel.

ImpactRepresents the level to which an issue has the potential of affecting the Business.

PriorityA calculated value based upon Impact and Urgency.This value can be used by the HAR AM team, to establish the order in which incident tickets should be considered and to resolve scheduling conflicts, as well as to manage workload.

Known ErrorKnown underlying cause. Successful diagnosis of the root cause of a Problem, and workaround or permanent solution has been identified

Work AroundThe pre-defined and documented technique in which to restore functionality to the Originator with the required functionality. A workaround is NOT a permanent (structural) solution and only addresses the symptoms of errors. These workarounds are stored in the KEDB.

Policies

Policy #Policy Statement

3.1Altering the priority policyTo alter the Priority of an Incident the impact and urgency must be reassessed. Any reassessment must occur prior to the resolution of an Incident. Approval must be obtained from the Originator prior to upgrading or downgrading the Priority of an Incident. Where the incident Priority has been altered, the reason and any obtained approvals must be entered in the remedy tool by the resolving group.

3.1Incident Life Cycle PolicyAn incident goes through different phases through its life cycle, the uses of the stages needs to be chosen only based on scenarios mentioned under : New: The initial state of an incident in which the concerned person records the incidents, feeds in the information and generates a unique incident number. The stage is automated and no manual intervention is required. Assigned: Post logging the Incident, the incident originator/Telia System Support assigns the incident to the appropriate resolver group. The status change is automated and does not require manual intervention. Work In Progress: Once the incident is assigned to a specific queue, a member of the specific support group has to acknowledge the Incident. The status must only be used by the specific resolver group and no one else. Work in progress is a status in which the SLA counter calculates the effort involved in actual resolution, the time spend on waiting for information, coordinating with a third party etc will not be a part of this status. Dormant: The status stops the SLA clock from ticking, for the following reasons -1) Used prior to assigning an incident back to the Telia System Support, in case more information is required from the user to resolve the incident. 2) In case HAR AM team would like a third party or an internal support group within Telia to extend support during the resolution process. HAR AM team dials the Telia System Support, provides the Incident/ Request number, and asks for support in transferring the record to the appropriate resolver group. The status of the ticket is changed from work in progress to Dormant.3) In case a change is required for an Incident to be resolved, the status of the Incident will reflect as Dormant, from the time the change is logged - till the time taken for the Change approvals, to the next available deployment window. Resolved: The status must be only used by a resolver group post validation of resolution, after applying the fix. Resolved status does not mean the closure of the Incident; the Originator receives a communication when the status is modified to Resolved and is further contacted by the Telia System Support team for confirmation. In case the Originator denies resolution, the Incident is assigned back to the HAR AM team. Closed: Incident is termed as closed once the originator is satisfied with the resolution and provides a formal communication to Telia System Support team for closure of the incident.

Process Workflow Process Workflow Description

Roles and Responsibilities

RoleOrganizationResponsibility

Incident InitiatorTelia Users/Customer Operation team/Capgemini/3rd PartyIncident Management process gets initiated by the Incident Initiator or through Event Management Logging an Incident in the Remedy tool or by calling Telia System Support team (+46) 020-909095) to log an Incident in the Remedy tool. Initiator can also email the issue to the Telia System Support common mail ID (DL-Systemsupport-Alla@tms.telia.se) to log an Incident.Providing any required information to the resolver groupConfirming of the resolution as required

Telia System Support teamTeliaThe Telia System Support team is responsible for the following:-Opening an Incident Record in the Remedy toolGathering any required information for the Incident Reviewing and modifying initial Incident priorityInteracting with Incident Initiator for any additional information Actively liaison with HAR AM team during the resolution processClosing the Incident

Incident ManagerCapgeminiThe Incident Manager is responsible for the following:-The Incident Manager is the owner of the incoming incidents and has the overall end-to-end responsibility for those incidents.Confirming that each Incident is responded to within the appropriate time frame Check on Incident are resolved within the stipulated time based on SLAsConducting Incident Review MeetingsMonitoring regular Incident measurementsAnalyzing incidents to identify and act on trendsManaging day-to-day Incident management issues Registering & assessing various situations that may require critical situation handlingPreparing and submitting monthly MIS report on Incident Management processProviding feedback to the appropriate parties regarding Incident routing errors.

HAR AM teamCapgeminiThe HAR AM team is responsible for the following:-The HAR AM team has overall responsibility for analyzing and resolving Incidents. Ensure all the details for Incident resolution are entered into the incident record.Reviewing the Incident Record for completenessContacting the Telia System Support team for additional information as required. Updating the Incident Record with any additional informationDeveloping Permanent Resolution Plans for IncidentsContacting other support groups to arrange for and schedule resources from other operational Processes to execute solution plan tasksCommunicating with 3rd PartyResolving the Incident Confirming that the solution resolves the IncidentCommunicating the status of resolution activities, as requiredNotifying appropriate parties of the success or failure of the resolution plan, as requiredRecording all actions and status updates in the Incident RecordProviding status as requested

3rd PartyInternal to Telia/Support Vendors/ContractorThe 3rd Party is responsible for the following:-External activities needed for restoration of services and functions.Resolution of Incident within the SLA time frameCommunicate with HAR AM team for additional informationProviding status as requested

ProcedureStandard Incident Management Lifecycle is basically broken into five stages: Incident Detection and Recording Incident Classification and Initial Support Investigation and Diagnosis Resolution and Recovery Incident Closure

Each stage is denoted as an activity and comprises of detailed tasks. These activities and associated tasks are outlined below.

Activity IM 1: Incident Detection & Recording

InputTasks ResponsibleOutput

Description of IncidentStep 1.1 Experience Issue/Request The general process is initiated by a Telia User/Customer Operation facing an issue and reporting it in the Remedy tool/or raising it via Telia System Support (L1Support).Status of Incident= NewCustomer Operation team/ Telia UsersAn Issue has been identified and reported through email / telephone / Online Portal.

Description of incident like type of service that got impactedStep 1.2 Log new Incident/Update existing Incident Recorda) Incidents are logged by Customer Operation team/ Telia Users in the Remedy tool.

b) Incidents are logged by support team performing proactive monitoring.

c) Incident can be logged by Customer Operation team/Telia Users by emailing to Telia System Support email ID - DL-Systemsupport-Alla@tms.telia.seStatus of Incident= NewCustomer Operation team/ Telia UsersNew Incident RecordUpdated incident record in case the originator is not satisfied with earlier resolutionUpdate in case the Telia System Support, Application Maintenance team provides inputs on an existing incident.

Description of IncidentStep 1.3 Call Telia System Support Customer Operation team/Telia Users can log Incident by calling to (+46) 020-909095)Status of Incident=NewCustomer Operation team/ Telia UsersLog an Incident ticket by calling Telia System Support team.

Description of IncidentStep 1.4 Log a new Incident/Update by L1 teama) Incidents are logged by Telia System Support team on Originator behalf.

b) Incidents are logged by support team performing proactive monitoring.

c) Incidents are updated by Telia System Support team for an existing incidentStatus of Incident=New AssignedTelia System SupportNew Incident RecordUpdate an Incident record

Activity IM 2: Incident Classification & Support 1st Level

Issue reported to Telia System Support by Customer Operation team/ Telia UsersStep 2.1 Incident Categorization and Prioritization Based on the Issue being reported to the Telia System Support via Phone, Email, or Online Portal, Telia System Support classifies the Incident based on the impact and urgency and accordingly set the priority of the incident. Status of Incident=WIPTelia System Support (L1 Support)Prioritized and categorized incident in the Remedy tool.

Prioritized and categorized incident in the Remedy ToolReference of incident resolution in Knowledge DatabaseStep 2.2 Incident Diagnosis and Update Incident DetailsBased on an initial diagnosis and reference to the Knowledge Database, the Telia System Support checks whether resolution of the incident is possible by them. a) Service Request process is invoked by Telia System Support team if the ticket is related to service request.b) However, If the Telia System Support identifies the Ticket as priority A Incident then Major Incidents process is triggered c) If a known solution exists, please refer to Activity 4: Resolution and Recovery (Apply Fix)Status of Incident=WIPTelia System Support (L1 Support)Resolution of the incident by Telia System Support based on self-analysis.Status Update of Incident in Remedy tool.Invoked Service Request processInvoked Major Incident Process

Updated Incident RecordStep 2.3 Determine Appropriate Resolver groupIn the case, Telia System Support cannot resolve the incident on its own; they pass the ticket to the appropriate resolver group.Status of Incident= AssignedTelia System Support (L1 Support)Status update of incident in the Remedy tool.Assign the Incident ticket to the resolver group

Updated Incident RecordStep 2.4 Accept the ticket and InvestigateUpon receipt of incident, the HAR AM team acknowledges its receipt to Telia System Support for adherence to Response SLAs in accordance with the agreed guidelines.a) However if the HAR AM team identifies the ticket as Service Request then, Service request process will be invoked.Status of Incident=WIPHAR AM team (L2 and L3 Support)Incident acknowledgement in the Remedy system for response SLAs in accordance with guidelines

Ticket assigned to HAR AM teamStep 2.5 Communicate to Telia System SupportHAR AM team member checks if the priority, category of the incident is correct and the incident is not out of scope for the HAR AM team. If its out of scope, HAR AM team communicates the same to Telia System Support team. Afterwards it is for the Telia System Support team to re-investigate the assignment of the ticket. The ticket status is set to Assigned in order to calculate the SLA properly.HAR AM team (L2 and L3 Support)Validation for out of scope incident and thereby routing to Telia System Support.

Activity IM 3: Investigation & Diagnosis

Incident acknowledged in the Remedy tool.Step IM 3.1, IM3.2 and IM3.3 Provide Requested Information Based on response from Telia System Support, for correct assignment of the incident, it will be handled by HAR AM team, anyway.After the ticket is acknowledged by HAR AM team, they validate the results of the initial classification by the Telia System Support. To ensure adequacy in resolution of incident, the HAR AM team ensures that the required information is available, if its in scope.If this is not the case, then the information is requested from Telia System Support which serves as an interface to the Originator and gathers the needed details. The ticket status is set to Dormant in order to calculate the SLA properly.This information gathering loop is conducted until all necessary information is present with the HAR AM Team properly.Status of Incident=WIP/DormantHAR AM team (L2 and L3 Support), Telia System Support team and Originator

Additional information is gathered as necessary

The ticket is allocated and all necessary information is gathered. Ticket Status = In ProgressStep IM 3.4 Perform Diagnosis (Detailed Impact Analysis)Based on the provided information, HAR AM team checks the Solution Database of similar incidents and their solutions. In the case, a suitable solution is present, the HAR AM team can immediately proceed applying the solution in the Resolution & Recovery phase.However, if no satisfactory solution is recorded, then the HAR AM team performs a detailed diagnosis of the Incident, including a detailed impact analysis, in order to fully examine the issue and prepare the resolution.If this diagnosis reveals, that resolution is not possible though workaround, then the Problem Management process gets triggered for permanent resolution of the incidentAlso, if a Change is needed, then the Change Management gets initiated. However, if the solution can be provided via the Incident Management process itself, then the activities progress further with the next phase i.e. Resolution & Recovery.Due to the activities of the Investigation & Diagnosis phase continues, the HAR AM team tracks all actions and outcomes in the Incident Record. Thus, a complete history of the event is provided, which is useful in resolution and in similar cases.Status of Incident=WIPHAR AM team (L2 and L3 Support)Impact analysis of the incident and its corresponding update in the system.Trigger for Problem Management / Change Management process for resolution of the issue.

Activity IM 4: Resolution & Recovery

Updated incident status in the Remedy tool based on completion of impact analysisStep IM 4.1 and IM4.2 Incident ticket assigned to 3rd PartyThe HAR AM team identifies the corresponding workaround / solution for fixing the incident. Within this step, HAR AM team identifies triggers for 3rd party support, as needed, for resolution of the incident. In this case, the HAR AM team hands over the ticket to 3rd party for providing the resolution. The status of the incident in the system at Capgemini is changed to Assigned.The 3rd party thereafter works towards Incident as described above. Upon completion of the resolution, the solution is communicated by the 3rd party to HAR AM team.The status of the incident in the system is now changed to In Progress.HAR AM team (L2 and L3 Support)3rd Party Workaround/Solution identified.Trigger for 3rd party support for resolution of incident, as needed.

Workaround / solution of the incident identified and updated in systemStep IM 4.3 Apply Solution / Perform TestingThe Telia System Support (from step IM2.3), HAR AM team continues further with providing the solution for fix of the Incident.Status of Incident=ResolvedHAR AM team (L2 and L3 Support), Telia System SupportWorkaround / solution are applied properly.

Activity IM 5: Closure

Resolution of the incident provided to Telia System Support for communication to Originator

Step IM 5.1 and IM 5.2 Incident ClosureThe HAR AM team communicates the resolution of the incident in accordance with the SLA to Telia System Support team, which further communicates the resolution to the Originator.In the case the user accepts the solution, the Telia System Support team receives this feedback and communicates the acceptance to HAR AM team. Based on the feedback received from the originator, Telia System Support team updates the incident record and closes the ticket by updating the ticket status to Closed.However, if the Originator is not satisfied with the solution the ticket is reassigned to HAR AM team with the updates.After providing resolution to incidents, if confirmation is not received from Originator to close the tickets, Telia System Support team will send three emails to the users and then close the ticket. The rule is also applicable for incidents where further information has been requested from the user and the user has failed to provide the details despite sending 3 intimations.Status of Incident= Closed AssignedHAR AM team (L2 and L3 Support), Telia System Support team, OriginatorResolution of the incident communicated to Originator for acceptance.Acceptance of ticket solution communicated to Telia System Support team and HAR AM teamIncident update in the system as Closed based on acceptance.Ticket is reassigned to HAR AM team if the Originator is not satisfied with the solution provided.

Incident Update in the system as Closed Step IM 5.3 Update KEDB at L1 SupportThe Telia System Support team (L1 Support) updates the Knowledge database with resolution of the incident. Status of Incident= ClosedTelia System Support teamUpdates in Knowledge Database with resolution of incidents

Incident update in the system as ClosedStep IM 5.3 Update KEDB at HAR AM team (L2 and L3 Support) The HAR AM team updates the Knowledge Database with resolution of the incident. This update of solution serves as future reference for incidents and also triggers for Continual Service Improvement in the engagement. Progress and status reporting is done for incidents to Capgemini Senior Management and Telia.Status of Incident= ClosedHAR AM team (L2 and L3 Support)Updates in Knowledge Database with resolution of incidentsWeekly & Monthly Status Reports for incidents

RACI Matrix for the Incident ManagementR ResponsibleA AccountableC ConsultedI Informed

Box Ref NoDescriptionCustomer Operations team/Telia UsersTelia System Support (L1 Support)HAR AM team (L2 and L3 support)3rd Party

IM 1.4Log New IncidentCR/A

IM 2.1Incident Categorization and Prioritization CR/A

IM 2.2Incident Diagnosis C/IR/AC/I

IM 2.3Determine Appropriate resolver groupIR/AC

IM 2.4Accept ticket and InvestigateIA/CR

IM 3.1Communicate to Telia System SupportC/IR/A

IM 3.2Need more informationC/IAR

IM 3.3Request for InformationARI

IM 3.4Provide requested informationRAC/I

IM 3.5Perform Diagnosis (Detailed Impact Analysis)ICR/A

IM 4.1Identify Workaround / SolutionIC/IR/AR

IM 4.2Apply Solution / workaroundIC/IR/AC

IM 4.3Incident ticket assigned to 3rd party IC/IR/AR

IM 5.1Communicate to the OriginatorIR/AR

IM 5.2Incident Closure C/IR/AI

IM 5.3Update KEDB at L1 Support onlyR/A

IM 5.4Update KEDB at HAR AM team onlyR/A

Measurements, Verifications & ReferencesSLA MeasurementsKPIPriority Level APriority Level BPriority Level CPriority Level D

Response timeImmediate4 hours2 working daysAnalyzed for possible further development

Resolution time2 hours8 hours5 working days

Status every 60 minutes2 hours//

The monthly IM statistics have to include: The number of Incidents Sources of the Incidents (including reference to the impacted Services) Frequency regarding the types or categories of Incidents The duration of open Incidents (average and quantities by age) Number of Incidents resolved Other pertinent information regarding Incident resolution, including Service Level measurement reportingVerification Monthly Incident manager review Service review meeting Senior Management reviews (Internally at Capgemini India) Process Reviews and Internal Audits (Internally at Capgemini India)Templates: Monthly Status Report Weekly Status Report Metrics Sheet (Internal at Capgemini India) Senior Management Review Report (Internal at Capgemini India) Peer Review Log (Internal at Capgemini)

Interfaces/References to Other ProcessesCapacity ManagementIncident Management provides a trigger for performance monitoring where there appears to be a performance problem. Capacity Management may develop workarounds for Incidents.Availability ManagementAvailability Management will use Incident Management data to determine the availability of IT services and look at where the incident lifecycle can be improved. Service Level Management The ability to resolve Incidents in a specified time is a key part of delivering an agreed level of service. Incident Management enables Service Level Management (SLM) to define measurable responses to service disruptions. It also provides reports that enable SLM to review Service Level Agreements objectively and regularly. In particular, Incident Management is able to assist in defining where services are at their weakest, so that SLM can define actions as part of the Service Improvement Program (SIP). SLM defines the acceptable levels of service within which Incident Management works, including:Incident response times Impact definitions Target fix times Service definitions, which are mapped to TeliaExpectations for providing feedback to TeliaChange ManagementWhere a change is required to implement a workaround or resolution, this will need to be logged as an RFC and progressed through Change Management. In turn, Incident Management is able to detect and Resolve Incidents that arise from failed changes.Configuration ManagementConfiguration Management provides the data used to identify and progress Incidents. One of the uses of the Configuration Management System (CMS) is to identify faulty equipment and to assess the impact of an incident. It is also used to identify the Customers affected by potential problems. The CMS also contains information about which categories of incident should be assigned to which support group. In turn, Incident Management can maintain the status of faulty CIs. It can also assist Configuration Management to audit the infrastructure when working to resolve an incident.Knowledge ManagementData held in Knowledge Management repository should be accessed when analyzing and diagnosing Incidents. Details of known errors and their workarounds should be documented in here to enable quicker resolution of Incidents either by Telia System Support or HAR AM team.Problem ManagementFor recurring incidents and major incidents Problem management is necessary to be carried out. Incidents are often caused by underlying problems, which must be solved to prevent the incident from recurring. Event ManagementEvent Management is the process that (automatically) monitors all events that occur through the IT infrastructure. Some events will raise an Incident; Incident Management will concentrate on restoring the service as quickly as Current.

GuidelinesAppendix A Incident ClassificationTickets are analyzed by the Telia System Support (L1 Support team) and by HAR AM team (L2 and L3 support). The classification of an incident depends on impact and urgency. The priority levels contain the Levels A (Critical Incident), B (high), C (medium) and D (low). Incidents identified as Major or highly impacting are classified as A Incident and thus get handled by the Major Incident Management processes.The incident gets analyzed regarding Impact and urgency.Impact is defined under ITIL as a measure of the business criticality of an Incident, often equal to the extent of a distortion of agreed or expected service levels. As such, it can be assessed based on the effect of an Incident on the Clients business operations. An Impact may be assessed by taking into account the number and business roles of the people affected or the business functions supported by the systems affected.Urgency is defined under ITIL as a measure of the business criticality of an Incident based on the impact and on the business needs of the customer. As such, it can be assessed based on how quickly the business of the Client will be affected by the loss of Service resulting from the Incident. A high-impact Incident does not necessarily have an immediate Impact. For example, a Telia System Supporting end-of-month processing (impact high) can be assessed as urgency low if it occurs early in the monthly processing cycle, but may be assessed as high if it nears the end of the cycle. A system that supports the staffs dealing directly with the Clients customers or that supports online, real-time transactions may always be assessed as a high urgency, even if it is only of moderate impact.

Priority A: An Incident will be assigned as Priority Level A, if the Incident is characterized by at least one of the following:(i) The Incident is one that has critical or significant impact through single or multiple or part IT system failures.(ii) The problems cause a complete loss of service or constitute a serious obstacle to essential parts of the Telia business and the Telia customers that are affected by the Object.(iii) The Incident is one that has a high impact on the operation of the affected Application or other Service and that cannot be circumvented (iv) The Incident, because of the immediacy of its effect on critical business functions, requires a Change be made on an immediate-response basis.(v) Class A incidents include e.g. corrupt data, a critical function not being accessible, the system hanging in an unidentifiable way, causing unacceptable or impossible delays for internal resources in the Object or delays to internal answers, system crashes or repeated system crashes during restart attempts.

Response time: Once a Priority Level A is acknowledged, it is required that the Support group starts work immediately on fixing it and that normal Service is restored as soon as possible and within the shortest Service Level of the affected Services.

Priority B: An Incident will be assigned as Priority Level B, if the Incident does not qualify for Priority Level A but is characterized by at least one of the following:(i) The Incident can materially affect the Client, causing a substantial impact.(ii) No acceptable Work Around is available, but operation can take place to a limited extent in the Object.(iii) The Incident is one that has an impact where Services are highly degraded to Telia Users at one or more primary Client locations.

Response time: Once a Priority Level B is acknowledged, it is required that the Support group starts work as soon as possible on fixing it (without adversely affecting the resolution of any Priority Level A Incidents) and that normal service is restored as soon as possible and within the shortest Service Level of the affected Services. Priority C: An Incident will be assigned as Priority Level C, if the Incident does not qualify for priority Level A or B but is characterized by the following:(i) The Incident does not materially affect the Client or does not cause a substantial impact, but has the potential to do so if not resolved expeditiously.(ii) The effect of the Incident is such that it does not require an immediate response(iii) The Incident is one that has an impact where services are degraded to Telia Users at a single non-primary Client location.

Response time: Once a Priority Level C is acknowledged, it is required that the Support group starts work as soon as possible on fixing it (without adversely affecting the resolution of any Priority Level A or Priority Level B Incidents) and that normal Service is restored as soon as possible and within the shortest Service Level of the affected Services.

Priority D: An Incident will be assigned as Priority Level D, if the Incident does not qualify for Priority Level A, B or C but is characterized by any of the following:(i) The Incident does not have an adverse impact on the business operations of Telia because of either the nature of the fault or the small extent of the fault and an acceptable work around is in place.(ii) The effect of the Incident is such that it does not require immediate resolution. (iii) The Incident is one that does not require immediate attention and no business critical Services are degraded or failed.(iv) The problems cause no loss in the operation of the Object and comprise minor incidents, incorrect behaviour or are not included in the documentation/operations manual for the Object.Response time: Once a Priority Level D is acknowledged, it is required that the Support group schedules the remediation work (without adversely affecting the resolution of any Priority Level A, Priority Level B or Priority Level C Incidents) such that normal Service is restored within the shortest Service Level of the affected Services.

Appendix B Knowledge DatabaseThe central knowledge database is used to capture, store and retrieve information and solutions for reuse by Support group. This Knowledge Database will enable the sharing of policies, procedures, best practices, and methods to resolve Incidents.

Appendix C EscalationEscalation is the mechanism that assists timely resolution of an Incident. It can take place during every activity in the resolution process. Escalation leads to the necessary management attention. The management will decide about additional measures, which will assist the resolution process or start interim solutions. The Incident Manager (IM) is the central point of escalation, wherein the escalation path is local Incident ManagerService Manager Telia SPOC.To be escalated are incidents which were not resolved in the time frames appropriate to the priority Level of the Incident and the priority of the Telia User. The escalation procedures reflect and describe the Incident, including: Priority of the Incident Location of the Incident and the name and/or number of affected Users Elapsed time before an Incident is escalated to the next higher Priority Level

Appendix E Reporting

Key issues related to Incident ManagementNumber of Incidents during the month, grouped by priority List of Incidents, short description, reference numberLinks to Problems and Known ErrorsTrend analysis of the Incidents reported during the 3 most recent monthsRisks related to the recurrence of Incidents or emerging trendsProposal Title|17