Fe)
FUJITSU
POA Customer Service Incident Management Process Details
COMMERCIAL IN CONFIDENCE
FUJ00080027
FUJ00080027
eo
Document Title:
Document Type:
Release:
Abstract:
Document Status:
Author & Dept:
Internal Distribution:
External Distribution:
Approval Authorities:
POA Customer Service Incident Management Process
Process Definition
HNG-X / HNG-X Application Roll Out Transitional Period / Pre HNG-
X Application Roll Out Transitional Period
This document describes the Customer Service Incident
Management Process
APPROVED
Liz Melrose — POA Service Delivery Team Manager
Peter Thompson, Liz Melrose, Tony Wicks, Mike Woolgar, Mike
Stewart, Graham Mockridge, Paul Gardner, Mik Peach, lan
Venables, Jan Ambrose, lan Mills, Brian Pinder
Sue Lowther POL Security Manager
Name
Naomi Elliott
Role
Director Customer Services
nature Date
Paul Gardner
HSD / SMC
Manager
Operations
Note: See Post Office Account HNG-X Reviewers/Approvers Role Matrix (PGM/DCM/ION/0001) for guidance.
©Copyright Fujitsu Services Ltd 2006
COMMERCIAL IN CONFIDENCE. Ref: ‘SVM/SDM/PRO/0018
Version: v2.0
Date: 02-APR-07
Page No: 1 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
Fe)
FUJITSU
COMMERCIAL IN CONFIDENCE
0 Document Control
0.1 Table of Contents
0 DOCUMENT CONTROL.........cscscsssssessnssssescesssssssesssessseeseasaestecseenenseeesensneseeeesaeaee 2
0.1 Table of Contents.
0.2 Document History.
0.3 Review Details..
0.4 Associated Documents (Internal & External).
0.5 Abbreviations.
0.6 Glossary...
0.7. Changes Expecte
0.8
0.9
1 INTRODUCTION.........cssssssssseseseeeessessssescsnsssssesssessutecneasasseseaeasacacesessnsseeseseeeeseeee 7
1.1 Process Owner..
1.2 Process Objective.
1.3. Process Rationale.
2 INPUTS. ......cccssssssscsssessseeseseacsnsscessrerseesesssssnecsssesesssecerececsessenssescesensenenecesesssseneeanessee 8
3 RISKS AND DEPENDENCIEG..........scsscssssssesseessssssssncssensseenssnssseesnsacsesaceessessensenes 9
3.1 Risks......
3.2 Dependencies.
4 RESOURCEG......cccscsssssssssssssssssseseseseesenenssnscscesensstasssseseseseasscacscsesseececesensaeeseaseses 10
5 PROCESS FLOW.
5.1 Level 1 Incident Management Process.
5.2 Level 2 Incident Management Processes.
5.2.1 Step 1: Incident Detecting, Recording and Initial Classi
5.2.2 Step 2: Assign Priority and Initial Support. .
5.2.3 Steps 3/4: Investigation and Diagnosis; Resolu' ion and Recover
5.2.4 Step 5: Incident Closure...
5.2.5 Step 6: Ownership, Monitoring, Tracking and ‘Communicatior
6 OUTPUTS. ......ccsscsssesesssssesteesessenssesesssnsesesscasesscsescatscesnsensesenecsenseneecssessnensenesesenens 20
7 STANDARDG.......cccscsssessssssssesssssesesesescersesessensssesessssesseasacscscsetsenenesneseneoeetasaseeseee 21
8 CONTROL MECHANISMG..........:ccscssscsesesssssessscseseesesssesesenesnensnsessnenensseesaseseenenee 22
9 APPENDIX A: SECURITY INCIDENT REPORTING........sssssssesssssssssserseeeseesseees 23
9.1 __ Scope, 23.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref. ‘SVM/SDM/PRO/0018
Version v2.0
Date: 02-APR-O7
Page No: 2 0f 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
9.2
9.3
9.4
9.5 IT Incidents...
9.5.1 Incident Defi z
9.5.2 Incident Categorie:
9.5.3 Examples of IT Incidents.
9.5.4 Containment
9.6 Reporting...
9.7 Investigation.
9.7.1 Policy.
9.7.2 POLS ly
9.7.3 External Investigator.
9.7.4 Evidence Rules.
9.7.5 — Process......
9.8 REMEDIAL ACTION.
9.8.1 On Completion of repo!
9.8.2 Completion of Investigation.
9.8.3 UNIRAS Reporting.
9.9 TRENDS & AUDITING.
9.9.1 Frequency.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-07
PageNo: 3 of 30
FUJ00080027
FUJ00080027
eo
POA Customer Service Incident Management Process Details
Fe)
FUJITSU
COMMERCIAL IN CONFIDENCE
0.2 Document History
Associated Change -
CP/PEAK/PPRR
Reference
Version No. Date
Summary of Changes and Reason for Issue
0.41 16/10/06 First draft taken from CS/PRO/074.
include HNG-X document references.
Updated to
Security Management appendix added
Incident Management Process modified to reflect
current working practises. Hardware and Network Call
priorities referenced
Problem Management escalation changed to SDM
rather than Problem Initiator.
1.0 06/11/06 Updated with comments following review of v0.1.
Issued for approval
14 02/03/07
2.0 Updated with comments following review of v1.1
Security Annex has been updated.
Issued for approval
0.3 Review Details
16" March 2007
Liz Melrose & PostOfficeAccountDocumentManagementi GRO:
Review Comments by
Review Comments to
Mandatory Review
Role Name
Head of Service Management Steve Denham
HSD / SMC Operations Manager
Optional Review
Paul Gardner *
FS CS Service Support Team Manager Peter Thompson
FS CS Business Continuity Manager Tony Wicks *
FS CS Service Delivery Manager BankOnLine Mike Woolgar
FS CS Service Delivery Manager Engineering
lan Venables *
FS CS Service Delivery Manager BankOnLine Mike Stewart
FS CS Service Delivery Manager DataTransfer Kirsty Walmsley
FS CS System Support Centre Manager Mik Peach *
FS CS Security Manager Brian Pinder
FS CS Security Pete Sewell
SMC Operations Manager lan Cooley *
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref. SVM/SDM/PROI0018
Version v2.0
Date: 02-APR-O7
PageNo: 4 of 30
Fe)
FUJITSU
POA Customer Service Incident Management Process Details
COMMERCIAL IN CONFIDENCE
FUJ00080027
FUJ00080027
(*) = Reviewers that returned comments
0.4 Associated Documents (Internal & External)
eference Versiot Date Title Source
PGM/DCM/TEM/0001 I 1.0 13/6/06 Fujitsu Services Post Office Account I Dimensions
(00 NOT REMOVE) HNG-X Document Template
CS/IFS/008 POA/POL Interface Agreement for I pycs
the Problem Management Interface
CS/PRD/021 POA Problem Management Process I pycs
CS/PRO/110 POA Problem Management I pycs
Database Procedures
PA/PRO/001 Change Control Process PVCS
CS/QMS/001 Customer Service Policy Manual Pvcs
‘SVM/SDM/SD/0001 Service Desk — Service Description I Dimensions
CS/FSP/002 Horizon System Helpdesk Call I pycs,
Enquiry Matrix and Incident
Prioritisation
CS/REQIO25 Horizon HSD 7 SMC: Requirements I pycs
Definition
SVM/SDM/PRO/0001 POA Major Incident Escalation I Dimensions
Process
CSIPLAI015 HSD/SMC Business Continuity Plan I pycs
SVM/SDM/SD/0002 Engineering Service Description Dimensions
Unless a specific version is referred to above, reference should be made to the current approved
versions of the documents.
0.5 Abbreviations
Abbreviation Definition
HSD / SMC Horizon Service Desk
Iso International Standards Organisation
ITIL Information Technology Infrastructure Library
KEL Known Error Log (in the context of this document, this is a workaround and
diagnostic database)
MSU Management Support Unit
OLA Operational Level Agreement
ORF Operational Review Forum
oTl Open Teleservice Interface
PO Post Office
POA Post Office Account
©Copyright Fujitsu Services Ltd 2006
COMMERCIAL IN CONFIDENCE. Ref: ‘SVM/SDM/PRO/0018
Version: v2.0
Date: 02-APR-O7
Page No: 5 of 30
2
FUJITSU
POA Customer Service Incident Management Process Details
COMMERCIAL IN CONFIDENCE
FUJ00080027
FUJ00080027
POL Post Office Limited
SDM(s) Service Delivery Manager(s)
SDU Service Delivery Unit
SLT Service Level Targets
SMC Systems Management Centre
SRRC Service Resilience & Recovery Catalogue
ssc System Support Centre
VIP VIP Post Office, High Profile Outlet
A+tG Advice & Guidance
BCP Business Continuity Plan
RFC Request For Change
KEDB Known Error Database
IMT Incident Management Team
PSE Product Support Engineers
SMT Service Management Team
OMDB Operational Management Database
NBSC Network Business Support Centre
UNIRAS Unified Incident Reporting & Alerting System
0.6 Glossary
0.7 Changes Expected
ee
0.8 Accuracy
Fujitsu Services endeavours to ensure that the information contained in this document is correct but, whilst every
effort is made to ensure the accuracy of such information, it accepts no liability for any loss (however caused)
sustained as a result of any error or omission in the same.
0.9 Copyright
© Copyright Fujitsu Services Limited 2006. All rights reserved. No part of this document may be reproduced,
stored or transmitted in any form without the prior written permission of Fujitsu Services
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref:
Version:
Date:
Page No:
‘SVM/SDM/PRO/0018
V2.0
02-APR-07
6 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
fee)
FUJITSU
COMMERCIAL IN CONFIDENCE
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-07
Page No: 7 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
Fe)
FUJITSU
COMMERCIAL IN CONFIDENCE
1 Introduction
1.1 Process Owner
The owners of this process are the Fujitsu HSD / SMC Operations Manager and the POA Service
Delivery Team Manager responsible for the Fujitsu contract.
1.2 Process Objective
The objective of this document is to define the process for Incident Management in the POA
environment. For the purpose of this document an Incident is defined as:
“Any event which is not part of the standard operation of a service and which causes, or may cause, an
interruption to, or a reduction in, the quality of that service.”
This process applies to all Incidents raised by the POA HSD or by SMC (out of hours or from systems
monitoring tools), where they are related to the Fujitsu outsourcing contract. N.B calls presented to POA
HSD / SMC that should be placed with the NBSC are transferred/ referred from POA HSD / SMC to
NBSC.
The scope of the process is from the receipt of an incident by the HSD / SMC, through to the successful
workaround or resolution of the incident.
For clarity it should be noted that the HSD / IMT are responsible for managing/owning Incidents during
business hours, with SMC assume this responsibility out of hours.
1.3 Process Rationale
The primary goal of the Incident Management process is to restore normal service operation as quickly
as possible, thereby minimising adverse impact to the business. In turn this ensures the highest level of
service quality and availability. Normal service operation is defined here as service operation within
Service Level Targets (SLT).
This process takes account of the requirements of improved service to be delivered to POL, through the
introduction of the HSD / SMC. The implementation of the IMT is documented and is aimed at
delivering improved understanding and communication between POL and POA leading to an increase in
the perceived service level within POL.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: v2.0
Date: 02-APR-07
PageNo: 8 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
2 ‘Inputs
The inputs to this process are:
e All Incidents reported by Contact with the HSD / SMC. Contact is defined as voice or Tivoli Alert as
the methods of communication with the HSD / SMC and fall into the following categories:
o Business process error
o Hardware or software error
o Request for information e.g. progress of a previously reported Incident
o Network Error
o Logging via HNG-X web interface
e Severity and SLT information.
e Evidence of an Error.
e System Alerts received automatically from OMDB. Due to the urgent nature of these alerts they will
be dealt with directly by SSC, with an update of workaround or resolution supplied to HSD / SMC. It
should be noted that these alerts enter the process at step 3, and are not subject to steps 1 & 2 of
this process.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
PageNo: 9 of 30
Fe)
FUJITSU
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
COMMERCIAL IN CONFIDENCE
3
Risks and Dependencies
3.1 Risks
The following define the risks to the successful delivery of the process:
Break in the communications chain to third parties. Mitigation is to invoke escalation procedures.
Non-availability of the HSD / SMC Incident Management System or HSD / SMC ONE systems.
Mitigation is given in the HSD / SMC Business Continuity Plan.
Non-availability of the OTI links to core & external service desk tools.
Lack of information given to the HSD / SMC regarding changes, POL Business updates, request for
changes, status of Problems etc. Processes must be followed to lessen this risk, such as the
Change Management and Problem Management Processes.
Unavailability of sufficient support unit staff
Unavailability of sufficient tools for Incident diagnosis
Non-availability of KEL or call management systems
The provision of inadequate staff training within the HSD / SMC, SDU’s or 3” party suppliers
Unavailability of systems for evidence gathering.
3.2 Dependencies
This process is dependent on:
Effective Incident handling by the HSD / SMC.
The known error information being available and kept up to date with all errors as the root cause
becomes known to Problem Management
e Knowledge database (HSD / SMC ONE) kept up to date with POL business and services knowledge
e Fujitsu infrastructure support of the HSD / SMC tools
e Appropriate training plans / skills transfer of desk agents.
e Appropriate training needs to include hardware, software and networks support staff, SDU’s and 3%
party suppliers
e Effective routing of calls to SDUs and third parties
« Effective escalation procedures and the maintenance thereof within Fujitsu, POL and third parties
e Governance of Incident / Problem Management procedures
e Effective feedback to POL through Service Management ORFs, contributing to end user education
and reduced Incident rates.
«Internal feedback to improve the Incident / Management Process.
e SLT and OLA knowledge and understanding across all Fujitsu and 3° party support
* POA, SDU and 3” party consistent co-operation in incident identification and resolution
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVMISDM/PROI0018
Version v2.0
Date: 02-APR-O7
Page No: 10 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
4 Resources
The resources required for this process are:
« Process Owners
e Incident Management Team
« Service Management Team
« HSD/SMC
« ssc
° SDU’'s
e Call Management System
« HSD/SMC ONE
° Peak
e Despatch 1
e TIVOLI
e Additional remote Management, Operational and Diagnostic tools
¢ Detailed Process and Procedure documentation
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 11 of 30,
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
fee)
FUJITSU
COMMERCIAL IN CONFIDENCE
5 Process Flow
5.1 Level 1 Incident Management Process
ds
al Incident Detecting, recording and initial
classification
v
2
a Assign priority and initial support
v
3.
Investigate and diagnose F Ly
v
<—— op
>! 4.
Resolution and recovery
5.
Incident closure
Problem Management
Ownership, monitoring, tracking, communication and end to end management
(POA Service Management)
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 12 of 30
oo
FUJITSU
POA Customer Service Incident Management Process Details
COMMERCIAL IN CONFIDENCE
FUJ00080027
FUJ00080027
5.2 Level 2 Incident Management Processes
5.2.1
Responsible: HSD / SMC, users, SDU’s, Service Management
Step 1: Incident Detecting, Recording and Initial Classification
la (< Senice
User (Syste \ management /
M
¥
fe
Contact received
eo 12 Yes
<Existing call of >
query?
yt
¥
ae Record Contact
advise caller of
Management
ao incident number
14 ba
Classification of call GO ves _
established _Ealler satistica YS .
Error Incident ~ Advise & with response? > >4 Contact ended )
Guidance - Out of Scope -
Quality -
il No
15
Advise caller of Call
Reference Number and
action according to
classification
¥ y ¥
Advise &
¥ ¥. ¥.
Advise caller of
To Incident Answer enquiry eee Escalation
Management and close or refer reel contact Procedure for
process step 2 to POL NBSC Seen POL NBSC
¥ ¥ ¥
To step To step To step I To step
ay) 5) 5) 5
1.1 An Incident is received through contact (see definition in Section 2.0 above) with the HSD / SMC.
from:
Users
Fujitsu SDUs
POA IT Service Management
Third Parties
eccee
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 13 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
« Fujitsu Service Delivery Management
1.2 The caller may be enquiring about an existing Incident. Details are provided and if the
response is satisfactory, contact is ended, moving the incident to step 5. If the caller is not
satisfied with the response, the relevant Escalation Procedure is invoked. In cases of Incidents
that are either taking an above average time (for this type of Incident) to resolve or involve
multiple SDU’s, the HSD / SMC alerts the relevant Service Delivery Manager to provide
focused management of the Incident.
1.3 For a new Incident, Contact details are recorded if not system generated. Details taken are
dependent upon the error reported. Typically they may include:
The user's name and unique ID number
Location and contact details
Alternative contact details (where appropriate)
Hardware details as appropriate
Software error details, including application use at point of failure where known
Business and User Impact
Description of Incident
Location access times
Caller assessment of the priority of the incident.
eco c ere c eee
1.4 Classification of Call determined as one of the following:
e Error Incident — invoke Incident Management Process Step 2
* Quality — record details of complaint or compliment and invoke the relevant
Escalation Procedure.
« Advice & Guidance — Cold Transfer to NBSC.
© Out of scope — if the call is not within scope for the services provided by Fujitsu
advise the caller of the correct number or refer to POL NBSC and close incident.
1.5 The caller is advised of call reference number and the incident follows the process as
appropriate for the nature of the call.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 14 of 30
oo
FUJITSU
POA Customer Service Incident Management Process Details
COMMERCIAL IN CONFIDENCE
FUJ00080027
FUJ00080027
5.2.2 Step 2: Assign Priority and Initial Support
Responsible: HSD / SMC
st
24
CCallect adaitional
Information trom
contact
22
Assign Severity
Level & Priority
x
“tar Incident?
No
24
Check HSO ONE
or matching
entries
No
y
25
‘Match on
Trigger
> I Escalation
Process
I Alert
I (Service
I contol)
Apply resolution or
“<ke08 in SD >
2
Attempt 1 Line
resolution of incident
"with help fom PSE'sI
Advise caller of
status of Incident
Workaround
sr
Link call to Master
Incident / Error
Record
La
Resolved?
No
Raise incident
‘record and pass to
SoU
To step
3
V7
[Link cal fo waster
Incident Record to
inform SDU of
additional
Tostep
3
2.1 The HSD / SMC agent collects additional information in order to determine the nature, impact
and urgency of the Incident.
©Copyright Fujitsu Services Ltd 2006
COMMERCIAL IN CONFIDENCE.
Ref:
Version
Date:
Page No:
‘SVM/SDM/PRO/0018
V2.0
02-APR-O7
15 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
2.2 Call Severity is assigned based on the impact and urgency as per the criteria in the table
below. Call Priority for Hardware and Network calls is assigned in accordance with the Priority
matrix as detailed in Engineering Service Description (SVM/SDM/SD/0002), a copy of which
each agent should have on their desk.
Severity I Importance I Definition
A Critical * BUSINESS STOPPED, a Post Office down, unable to process any business, or
central system failure which will result in a number of Post Offices being unable to
process work.
B Major * BUSINESS RESTRICTED, a Post Office restricted in its ability to transact business,
eg. one counter down.
c Medium + NON-CRITICAL, a Post Office working normally but with a known disability, e.g. an
interim solution (workaround) has been provided
D Low . INTERNAL, an internal HSH/HIT/SMC problem, e.g. a Service Desk PC or a phone
set inoperable
2.3 If the incident is considered a Major Incident as defined in SVM/SDM/PRO/0001 Major
Incident Process, the Major Incident Procedures are invoked.
2.4 The HSD / SMC agent then attempts to resolve the Incident using the resources available.
This starts by interrogating HSD / SMC ONE to find all information related to the Incident
symptoms. If the Incident is routine, i.e. there is a predetermined route for resolution, then the
Incident is resolved on the call or referred to the relevant SDU using the HSD / SMC Support
Matrix in HSD / SMC ONE.
2.5 If the Incident is not routine, the HSD / SMC agent checks for Known Errors listed in HSD /
SMC ONE and the SSC KEL against records relating to the Incident symptoms. If a match is
found, the agent informs the caller of the workaround or resolution available.
2.6 If there is no match in HSD / SMC ONE or the SSC KEL, the HSD / SMC Incident
Management System stack is checked for current incidents outstanding. If a match is made,
the caller is then advised of the status of the incident and the master record is updated to
reflect the current occurrence.
2.7 \f no match is made against the HSD / SMC Incident Management System stack, the HSD /
SMC continues with first line resolution of the Incident assisted by the Product Support
Engineers (PSE’s). IMT are appraised of the position.
2.8 If the PSE’s cannot resolve the Incident, it is referred to the relevant SDU using the HSD /
SMC Support Matrix in HSD / SMC ONE. IMT are appraised of the position. For Hardware
calls, the caller is given an indication of engineer arrival time, based on the SLA associated
with the priority of the call.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 16 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
fee)
FUJITSU
COMMERCIAL IN CONFIDENCE
5.2.3. Steps 3/4: Investigation and Diagnosis; Resolution and
Recovery
Responsible: SDU’s
2nd line support stage. The referred SDU investigates and diagnoses the Incident, based on
information already taken by the HSD / SMC, together with any new information. The SDU also
coordinates where sub-contract third parties are involved. If the Incident has no associated KEL, or
it is complex and involves multiple SDU’s, or if it has been unresolved for an extended period, the
IMT will alert the POA Service Delivery Manager to the existence of a pattern likely to produce a
Problem.
Out of hours, SMC should check the OLA documentation to determine if out of hours support is
available for the Service impacted. In the event that out of hours support is available, SMC will
discuss incidents with the Duty Manager, who in turn will discuss incidents with the line of business
SDM.
Step 2
step 3 Pf
3
. 2 line investigate
>» "and diagnose ~ >
Coordinate 3
parties.
IMT to alert POA SOM
to the existence of a
pattern ikely to produce
From
‘695,
step 4
a
at
Produce
Workaround of
Resolution
—%
Resolve Incident ~
Master incident
Record remains
open
a
Check existing
details in SD
ONE 6 flag to
inclise current
x
oo IMT to alert POA SOM
‘Multipte occurrence. Yes tothe existence of @
proactive action or root >) I pattern tkely 10
“cause required? produce a Problem
No
x
45
Pass incident back
to service desk
‘inelu ding
description of
Incident
Management to
date
:
3
4.1 A workaround or resolution is produced by the SDU.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 17 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
4.2 The SDU then either applies the workaround or resolution or passes it to the HSD / SMC to
implement. The Master Incident Record (if one exists) remains open at this point.
4.3 The SDU checks the workaround or resolution has been successful. SD / SMC are
responsible for updating details recorded in HSD / SMC ONE, from details supplied via the
KEL created by SSC. HSD / SMC ONE should be identical to SSC KEL in relation to
Application Software, but may also contain additional information.
4.4 Where this Incident has a number of Calls referenced to it, or where there is a probability that
proactive action is required to prevent further occurrences of this Incident the IMT will alert the
POA SDM to the existence of a pattern likely to produce a Problem
4.5 The Incident is then passed to the HSD / SMC to manage the closure
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 18 of 30
FUJ00080027
FUJ00080027
(oe) POA Customer Service Incident Management Process Details
FUJITSU
COMMERCIAL IN CONFIDENCE
5.2.4 Step 5: Incident Closure
Responsible: HSD / SMC
Closure from
Escalation
Process
Tom
Steps
1,2&4
5.1
No Caller agrees
Incident
resolved? ~
Close call record I
The Call is then closed with the agreement of the originator. If not, it will be returned to the SDU to be
reworked.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 19 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
5.1.5 Step 6: Ownership, Monitoring, Tracking and Communication
Responsible: HSD / SMC, SSC
Throughout the Incident, the HSD / SMC retains ownership for monitoring and keeping the call raiser
informed of progress, unless the incident is specifically software related, in which case SSC hold the
responsibility for confirming details of closure.
The HSD / SMC manages the complete end-to-end Incident process.
Activities include:
e Regularly monitoring the status and progress towards resolution of all open Incidents
e Note Incidents that move between different specialist support groups, indicative of uncertainty
and possibly a dispute between support staff
e Give priority for Incident monitoring to high-impact Incidents
e Keep affected users informed of progress without waiting for them to call, thus creating a pro-
active profile
e Monitors SLT and escalates accordingly. If an Incident has no associated KEL or, it is complex
and involves multiple SDU’s, or if it has been unresolved for an extended period, IMT will alert
the POA SDM to the existence of a pattern likely to produce a Problem.
e Updating HSD / SMC ONE from information supplied from SSC KEL. This may be applied as a
direct copy or amended for use by the agents, dependant upon the technical complexity of the
update.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref. ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 20 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
6 Outputs
The outputs from this process are:
e A Problem referred to the Service Delivery Manager with line of business responsibility, where there
have been one or more Incidents for which the underlying cause is unknown
e Anupdate to the Knowledge Database
« Aworkaround or permanent resolution for a hardware, software or network error
e An answer to a question from a user
e The receipt and onward transfer of information received by the HSD / SMC.
e Aservice improvement recommendation.
« Change of operations procedures.
e Change of Business Continuity Plan (BCP) priorities and documentation.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVMISDM/PROI0018
Version: v2.0
Date: 02-APR-O7
Page No: 21 of 30,
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
7 Standards
This Process conforms to:
« Process Management and Control PA/PRO/038
e ITIL Best Practice
* BS15000
« BS9001
« BS/ISO IEC 27001
« IEC 17799:2005
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 22 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
8 Control Mechanisms
The contractual measures that apply to this service are described in the Horizon HSD / SMC Service
Description (SVM/SDM/SD/0001)
This covers service availability, service principles, service definition, incident prioritisation, service
targets and limits and HSD / SMC performance reporting.
In addition, internal measures may apply for specific productivity and service improvement activities.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 23 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
Fe)
FUJITSU
COMMERCIAL IN CONFIDENCE
9 Appendix A: Security Incident Reporting
9.1 Scope
This annex outlines the process regarding the investigation, and reporting of all security incidents
concerning the HORIZON Network and all IT equipment.
9.2 Aim
The aim of these instructions is to ensure that details of all IT related security incidents are reported to
one central point and that any follow up investigations are managed in an efficient and auditable manner.
9.3 Changes
These work instructions are primarily for use by HORIZON Service Desk Staff, the POA Security Team,
the POL Security Team, and SSC staff. Approval from POL is to be gained before any significant
changes to the work instructions are implemented. All readers are encouraged to propose changes to
Work Instructions, in writing, to the POA Security Manager.
9.4 POL Incident Handling Guidance,
All POL incidents will still be handled in accordance with existing POL guidelines. This document does
not replace these, or, indeed, replace any part of the content - rather it lays down the POAccount
framework under which the work is carried out.
9.5 IT Incidents
9.5.1 Incident Definition
9.5.1.1. An information security Incident is: "an adverse event or series of events that compromises
the confidentiality, integrity or availability of Fujitsu Services Post Office Account information or
information technology assets, having an adverse impact on Fujitsu Services reputation, brand,
performance or ability to meet its regulatory or legal obligations." This will also extend to include assets
entrusted to Fujitsu including data belonging to Post Office Ltd, its clients and its customers.
9.5.2 Incident Categories
Incidents can be categorised in many ways, they can occur alone or in combination with other incident
categories and can vary significantly in severity and impact. It is important that all incidents are
recognised and acted upon.
9.5.2.1 For the purpose of illustrating the impact of incidents two levels of severity have been
defined (Note: in practice the assessment may be less straightforward):
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: v2.0
Date: 02-APR-O7
Page No: 24 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
Fe)
FUJITSU
COMMERCIAL IN CONFIDENCE
A MINOR incident will normally have limited and localised impact and be confined to one domain,
resulting in one or more of the following:
e Loss or unauthorised disclosure of internal or sensitive material leading to minor
exposure, or minor damage of reputation
e Loss of integrity within the system application or data, leading minimal damage of
reputation; minimal loss of customer / supplier / stakeholder confidence; negligible cost
of recovery
e Loss of service availability within the domain, leading to reduced ability to conduct
business as usual; negligible loss of revenue; minimal loss of customer / supplier /
stakeholder confidence; negligible cost of recovery
A MAJOR incident will have a significant impact on the Network Banking Automation Community
resulting in one of more of the following:
e Loss or unauthorised disclosure of confidential or strictly confidential material, leading to
brand or reputation damage; legal action by employees, clients, customers, partners or
other external parties
e Loss of integrity of the applications or data, leading to brand or reputation damage; loss
of customer / supplier / client confidence; cost of recovery
e Loss of service availability for applications or communications networks, leading to an
inability to conduct business as usual; loss of revenue; loss of customer / supplier / client
confidence; cost of recovery
9.5.3 Examples of IT Incidents
e Theft of IT equipment / property, including software
e Malicious damage to IT equipment /property, including software
e Theft or loss of Protectively Marked, caveat or sensitive IT Data.
e Actual or suspected attacks on the Fujitsu Services POA Network or Information
System.
e Potential compromise of systems or services at the Data Centre through evidence
retrieved and presented by Police.
e Attacks on Fujitsu Services Post Office Account personnel via Information Systems. (I.e.
Harassment, Duress
e Malicious/offensive/threatening/obscene emails.
e Obscene phone calls
e Breaches of software licensing
e Virus attack and other malicious code attacks
¢ Hacker attacks
e Terrorist attacks
¢ Insider attacks
e Competitive Intelligence gathering (Unethically)
e Unauthorised acts by employees
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: v2.0
Date: 02-APR-O7
Page No: 25 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
Fe)
FUJITSU
COMMERCIAL IN CONFIDENCE
e Employee error
e Hardware or software malfunction
e Suspected Fraudulent Activity
The above list is examples, and by no means exhaustive. Any other IT related
incidents reported, will be considered and passed to the appropriate authority for
action.
9.5.4 Containment
Whenever an Incident is identified which presents a serious threat to conduct normal business it should
be contained and isolated as quickly as possible. This will mean Platforms that appear to have suffered
virus attack or other malicious code attack need to be quarantined immediately to prevent further
spread. It may also be necessary to isolate network connections that appear to be the source for Denial
of Service threats or where they have been subjected to suspected hacking attack.
9.6 Reporting
9.6.1.1. Anyone reporting a security Incident should be encouraged to notify their Line Manager in
the first instance. The Line Manager will gather as much detail of the incident as possible, following
company procedures. He or she will undertake an initial local investigation into the incident, ensuring
that in the case of missing equipment or materials that they have not just been misplaced.
9.6.1.2 If the severity of the Incident is considered as Minor but shows that an incident has occurred
that warrants further investigation the Line Manager should immediately log a call with the Post Office
Account Service Desk, stating that they are reporting a security incident, giving brief details. Please note
that in certain cases there may be circumstances where no details of a sensitive, nature should appear
on the call log. Having logged the call and obtained a call reference number, the Line Manager may then
continue with the investigation, and act as a liaison between the person reporting and all concerned
parties. Once logged, the investigation will thereafter be referred to by the Call Number.
9.6.1.3 All Incidents reported to the Service Desk with a call reference and even when classified as
Minor should still be forwarded to POA Security Management to determine if there is a Security Impact.
It is important that for any incident investigated the correct procedures are adopted regarding evidence.
9.6.1.4 If the severity of the Incident is considered as Major the Incident details must be reported
directly to the POA Security Manager immediately. Contact details are available on Café VIK.
Depending on the type of Incident and the severity of the incident POA Security will make the decision to
escalate the details to the POL Security. In the case of Data Centre incidents specifically Security will
also inform the Data Centre Manager if this has not already been done.
9.6.1.5 In all cases relevant details should only be recorded and discussed as necessary between
the person investigating or Line Manager dealing with it and any relevant parties who need to be
included in the investigation. Information on any incident must not be passed to anyone who is not
directly involved with the investigation without the authority of POA Security Manager.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: v2.0
Date: 02-APR-O7
Page No: 26 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
9.6.1.6 I Once a call is raised with the SSC the call will then be placed on the call stack of the POA
Security Team, who will monitor the incident, assist or advise the Line Manager if required, and be
available to take over the investigation should the need arise, but always be able to respond, within 2
hours of the initial call being made. (Minor Incidents (during normal working hours of between 9am and
5pm) and Major Incidents at all times.)
9.7 Investigation
9.7.1 Policy
Although all security incidents will initially be reported to the POA Security Manager in order to have one
point of contact for all parties, some or all of the investigation requirements may be passed to one or
more of the following for further action: The decision of delegation will be determined by the POA
Security Manager.
9.7.2 POL Security / Investigation Team
9.7.2.1 In the event that the reporting of an incident is passed to POL Security or the Investigation
Team, all details of the investigation, and final outcome or reference details, should be recorded on the
initial case report (ICR) and details will be recorded in the security Incident Log. It is important that for
any incident investigated the correct procedures are adopted regarding evidence.
9.7.2.2 In the event that the POA Security Manager takes ownership of an investigation, he will
report the results to POL Security.
9.7.2.3 During any investigation the Investigator must comply with the appropriate legislation and
regulations or standard requirements.
9.7.2.4 All initial investigations should be carried out at the earliest opportunity and any queries
should be directed to POA Security Manager. Investigation must be reliable, stand up to scrutiny and
potential cross-examination and evidence must be properly obtained.
9.7.3 External Investigator
9.7.3.1 Should it be considered necessary the incident might be passed to an external Investigator or
forensics team, who will ensure that any data required for evidential purposes is captured and
investigated using a systematic approach which ensures that an auditable record of evidence is
maintained and can be retrieved.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 27 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
9.7.4 Evidence Rules
9.7.4.1 Rules of Evidence
Before undertaking security incident investigation and computer forensics it is essential that investigators
have a thorough understanding of the Rules of Evidence. The submission of evidence in any type of
legal proceedings generally amounts to a significant challenge, but when computers are involved the
problems are intensified. Special knowledge is needed to locate and collect evidence, and special care is
required to preserve and transport evidence. Evidence in computer crime cases may differ from
traditional forms of evidence in as much as most computer related evidence is intangible and is in the
form of electronic pulse or magnetic charge.
9.7.4.2 Types of Evidence
Many types of evidence can be offered in court to prove the truth of falsity of a given fact.
The most common forms of evidence are Direct, Real, Documentary and Demonstrative.
Direct Evidence
Direct evidence is oral testimony whereby the knowledge is obtained from any of the witness’s five
senses and is in itself proof or disproof of a fact in issue. Direct evidence is called to prove a specific act
such as an eye witness statement.
Real Evidence
Real evidence also known as associative or physical evidence is made up of tangible evidence that
proves or disproves guilt. Physical evidence includes such things as tools used in the crime, and
perishable evidence capable of reproduction etc. The purpose of physical evidence is to link the suspect
to the scene of the crime. It is that evidence that has material existence and can be presented to the
view of the court and jury for consideration.
Documentary Evidence
Documentary evidence is presented to the court in forms of business records, manuals, printouts etc.
Much of the evidence submitted in a computer crime case is documentary evidence.
Demonstrative Evidence
Demonstrative evidence is evidence used to aid the jury. It may be in the form of a model, experiment,
chart or an illustration offered as proof.
9.7.5 Process
In most cases response to a reported incident the initial investigation will be carried out by a nominated
investigator normally the POA Security Manager or his nominated deputy. POA and POL Security
Teams will be on hand to provide backup and assistance if required. When seizing evidence from a
computer related crime the investigator should collect any and all physical evidence such as the
personnel computer, peripherals, notepads and documentation etc., in addition to computer generated
evidence.
There are four types of Computer generated evidence they are:
e Visual Output on a monitor
e Printed evidence on a plotter
e Printed evidence on a printer
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 28 of 30
FUJ00080027
FUJ00080027
POA Customer Service Incident Management Process Details
2
FUJITSU
COMMERCIAL IN CONFIDENCE
e Film recordings on such devises as disc, tape or cartridge, and optical representation on either
CD or DVD.
The investigator will endeavour to obtain as much original evidence as possible. In the event of a court
appearance the court prefers the original evidence rather that a copy but will accept a duplicate if the
original is lost or destroyed or is in the possession of a third party who cannot be subpoenaed.
9.7.5.1 Following the initial investigation and where considered appropriate, the investigator will
report to/ liaise with the local Police and/or other external Agencies; this will only be done following
consultation with the POL Head of security or her staff.
9.7.5.2 Copies of the initial and follow up reports will be submitted to relevant authorities and details
of all investigations will be held on file by the POA Security to aid any subsequent trend analysis.
9.8 REMEDIAL ACTION
9.8.1. On Completion of report
When the final report of an investigation has been completed, it should be passed to the relevant
authority for follow up action, the results of which should be referred back to the POA Security Manager.
9.8.2 Completion of Investigation
When an investigation is closed the POA Security Manager will ensure all details of the investigation
have been recorded and can be made available for subsequent future analysis.
9.8.3 UNIRAS Reporting
On call closure, the POA Security Team will complete and notify UNIRAS where required.
9.9 TRENDS & AUDITING
9.9.1 Frequency
9.9.1.1 POA Security Team will carry out a 6 monthly check of all investigations and create a
summary report highlighting all incidents to the POL Head of security.
9.9.1.2 The report will highlight any trends or weaknesses which may need to be raised at future
Security Forums.
9.9.1.3 Details from the 6 monthly reports may also be considered suitable for Line Managers.
©Copyright Fujitsu Services Ltd 2006 COMMERCIAL IN CONFIDENCE Ref: ‘SVM/SDM/PRO/0018
Version: V2.0
Date: 02-APR-O7
Page No: 29 of 30