Managed Services Handbook

Managed Services Handbook

Contents 1. Document Control... 4 Version Control... 4 Approvers... 4 Document Review... 4 2. Introduction... 5 2.1 How to Contact ANS... 5 2.2 Service Hours... 5 2.3 ANS Escalation Procedure... 5 3. Incident Management... 6 3.1 Named Contacts... 6 3.2 Escalation Contacts... 6 3.3 Logging a New Incident... 6 3.4 Criteria for Resolution... 7 3.5 Incident Handling... 7 3.6 Priority Definitions... 7 3.6.1 Incident Assessment Matrix:... 7 3.6.2 Priority 1 (P1)... 7 3.6.3 Priority 2 (P2)... 8 3.6.4 Priority 3 (P3)... 8 3.6.5 Priority 4 (P4)... 8 3.6.6 Priority 5 (P5)... 8 3.7 Out of Hours Service... 8 4. Service Level Agreements (SLAs) and Key Performance Indicators (KPIs)... 9 5. Problem Management... 9 6. Change Management... 9 6.1 Request for Change (RfC)... 9 6.2 Standard Changes... 10 6.3 Emergency Changes... 10 6.4 rmal Changes... 10 6.5 Change Advisory Board (CAB)... 11 6.6 Emergency Change Advisory Board (ECAB)... 11 6.7 CAB Approval and Rejection of Changes... 11 7. Service Management... 12 7.1 Service Review... 12 8. Customer Responsibilities... 12 8.1 Maintenance and Care... 12 8.2 Maintenance Windows... 13 8.3 Exclusions from ANS Managed service... 13 9. Enhanced Monitoring and Event Management... 13 9.1 Enhanced Monitoring System... 13 9.2 Event types Informational, Warnings and Critical... 14 10. Release Management... 14 10.1 Release Management... 14 10.2 OS Patch Management... 14 11. Additional Service Charges... 15 12. APPENDIX A ANS Escalation Procedure... 16 13. APPENDIX B ANS Incident Management Workflow... 17 14. APPENDIX C ANS Major Incident Management Workflow... 18 15. APPENDIX D ANS Problem Management Workflow... 19 16. APPENDIX E ANS Event Management Workflow... 20 17. APPENDIX F ANS Change Management Workflow... 21 18. Appendix G - Emergency Change... 22 19. Appendix H Release Management... 23 20. Appendix I OS Patch Management- Example... 24 21. APPENDIX J ANS Managed Service Offerings... 25 Page 2 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

22. APPENDIX K ANS Request for Change (RfC) Form... 26 23. Appendix L Standard Change list... 28 23.1... 28 23.2 General Changes... 28 23.3 I-Apps Changes... 28 23.4 Infrastructure Changes... 29 23.5 Network Device Changes... 31 24. Appendix M Service Level Management... 32 Page 3 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

1. Document Control Version Control Date Version Summary of changes 06/08/12 V0.1 Initial Draft 28/08/12 V0.2 Updated IM, Problem and Change processes added. 03/09/12 V0.3 Added Change Management details and updated RFC 03/09/12 V1.0 Updated Template and approved for release 26/03/13 V1.1 Updated Event Management process 03/04/13 V1.2 Updated Change risk assessment matrix and SLM flow added 26/07/13 V1.3 Updated Incident and Problem flows 17/10/13 V1.4 Reviewed and updated branding Approvers Name Paul Shannon Chris Hodgson Steve Breen Role Managed Services Director Head of Service Delivery Service Desk Manager Document Review This document will be reviewed and updated as necessary, as defined below: When required to correct or enhance content. Following changes to the ITIL or ISO quality system standards as defined by ANS. Following any organisation changes or restructuring. more than 12 months after the previous approval date. Page 4 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

2. Introduction The ANS Group Managed Services Handbook is intended to provide details of the Support Service offerings from ANS to our Managed Services customers. This document will further detail working processes, procedures and definitions of terms utilised by ANS in delivering Managed Services. Customers are advised to refer to their individual Service Definition Document (SDD) for confirmation of specific Service Level Agreements and offerings. Further details of the various services included in ANS Managed Service offerings are available in Appendix J. 2.1 How to Contact ANS There are a number of methods available for contacting the ANS team: General Enquiries: 0161 227 1000 Service Desk Telephone during rmal Business Hours: 0161 227 1010 Service Desk Telephone Out of Hours: 0161 227 1055 Email during rmal Business Hours: servicedesk@ansgroup.co.uk 2.2 Service Hours rmal Business Hours 09:00-17:30, Monday to Friday (excluding bank holidays) Extended Hours* 06:00-22:00, 7 days a week 24 x 7 24 hours a day, 7 days a week * - Extended Hours are currently only applicable to NetApp disk replacements. 2.3 ANS Escalation Procedure Appendix A of this document contains a copy of our Escalation Procedure. Page 5 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

3. Incident Management All incidents will be recorded in the ANS Service Desk ITSM system under the Incident Management workflow. ANS records the name of the person reporting the incident, the time of the call and any other pertinent information, along with criteria for resolution to ensure that the workflow is initiated correctly. Please note that support for customer-initiated Business Critical Issues is via telephone only and we cannot offer any SLAs for Business Critical Issues via email. 3.1 Named Contacts The service is available to a defined list of Named Contacts agreed within your SDD. If you require a change to this list please complete a CHANGE NAMED CONTACT REQUEST form, which can be downloaded from the ANS extranet at www.ansgroup.co.uk/ms-documents, and send to servicedesk@ansgroup.co.uk. Please note that the sender must be also a Named Contact on the SDD. 3.2 Escalation Contacts Escalation Contacts are the relevant Stakeholders within the customer organisation that will be informed of the status of any P1 incidents. This will take the form of automated emails and phone calls(where applicable). If you require a change to this list please email contracts@ansgroup.co.uk. The sender must be a Named Contact on the SDD. 3.3 Logging a New Incident Details required when logging a new incident: Customer name Contact name Product/Server name or serial number (if applicable) Details of symptoms experienced Details of any recent changes Impact to the business Effect on systems/services All new incidents will undergo an initial impact assessment. ANS will further look to determine the number of users/systems affected and establish the commercial impact to the client s environment. Please refer to section 3.6.1 for the Incident Impact Assessment Matrix. When logging an incident via email it is expected that the originator will provide the above information at a minimum, plus any screen shots, diagnostic data and/or diagrams as necessary. Please note that Incident response times will be delayed should this information not be provided. Page 6 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

3.4 Criteria for Resolution The criteria for resolution are agreed as part of the impact assessment. When the criteria are met the incident is deemed to be resolved, at which point the ANS Service Desk will contact the originator to confirm authority to close the incident. 3.5 Incident Handling Once logged, Incidents are managed within ANS ITSM system in-line with the assigned priority. All actions and associated updates are logged throughout the Incident lifecycle with periodic updates sent to the originator. On resolution, the ANS Service Desk will contact the originator to confirm authority to close the Incident. Please note that the ANS Service Desk will make a maximum of three attempts to contact the Incident originator in order to confirm authority to close. If all three attempts to make contact are unsuccessful, the Incident will be closed automatically with notification sent to the originator via email. Please refer to Appendix B of this document for the Incident Management workflow. 3.6 Priority Definitions 3.6.1 Incident Assessment Matrix: Affect Business Impact Minor Moderate Major Critical System/Service Down P3 P2 P1 P1 System/Service Affected P4 P3 P2 P1 User Down/Affected P5 P4 P3 P2 3.6.2 Priority 1 (P1) At this priority level both ANS and the customer must commit to round-the-clock response times and involvement by all necessary and appropriate personnel/systems until a mutually agreeable workaround is provided and the priority is no longer considered to be P1. ANS classifies all P1 Incidents as Major Incidents (MI). Please refer to Appendix C for the ANS MI Workflow. Examples of a P1 Incident include: server, node, system or cluster is down, unable to serve data, is in a state of frequent or repeating crash, panic or hang or is in a state of degraded performance sufficient to prevent critical business operations. Page 7 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

3.6.3 Priority 2 (P2) At this priority level ANS is committed to a commercially reasonable effort to provide a workaround and/or restore normal operations as quickly as possible during rmal Business Hours. Examples of a P2 Incident include: server, node, system, or cluster is experiencing an infrequent, isolated or intermittent crash, panic or hang, or is in a state of degraded performance that allows business operations to continue but at an inconsistent or less than optimal rate. 3.6.4 Priority 3 (P3) At this priority level ANS will, during rmal Business Hours, work towards a viable and mutually agreeable workaround or propose an upgrade or replacement to mitigate the problem. Examples of a P3 Incident include: server, node, system, or cluster is experiencing an issue, anomaly or cosmetic defect that inflicts little or no business impact. 3.6.5 Priority 4 (P4) At this priority level ANS will, during rmal Business Hours, provide advice on whether a workaround, upgrade or replacement to mitigate an issue is available. 3.6.6 Priority 5 (P5) At this priority level ANS will, during rmal Business Hours, provide answers to How do I? type queries. 3.7 Out of Hours Service ANS provides 24x7x365 access to its Service Desk for critical system down scenarios Priority 1 (P1) only. ANS has a number of Technical Analysts available covering multiple technologies. Once a call is taken it is logged in our Service Desk system and then passed to a Technical Analyst who specialises in that technology. The Out of Hours Service also provides access to the Duty Manager should further escalation or assistance be required. In order to access the Out of Hours Service, please call the Out of Hours number specified in section 1.1. Please note that this service may be subject to Additional Service Charges if not within the scope of your SDD. Please see Additional Service Charges for more information. Page 8 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

4. Service Level Agreements (SLAs) and Key Performance Indicators (KPIs) Please refer to your SDD for information on your specific Service Level Agreements and Key Performance Indicators. 5. Problem Management A problem may be the cause of one or more Incidents, although the cause is not usually known at the time the problem record is created. In order to prevent problems and resulting Incidents from reoccurring, our problem management process is used to determine the problem s root cause. The process is also designed to minimise the impact of problems that cannot be avoided. A problem can be detected by a number of sources, including but not limited to: The Service Desk from a specific incident Monitoring alerts Incident Trend Analysis tification from vendor/security Incident ANS Known Issues/Errors list When a problem is raised, ANS will gather all necessary information and perform Root Cause Analysis. If a solution is possible it will be applied and documented. If the Technical Analyst cannot find a solution, the problem will be escalated internally and then to the vendor as necessary. If a Change is needed in order to fix a problem then a Request for Change will be initiated and put through the Change Management Process. At the point of resolution, the Service Desk will contact the originator in order to gain approval to close. Any open or held problem-related Incidents will subsequently be resolved and closed. Appendix D contains a copy of the ANS Problem Management Workflow. 6. Change Management 6.1 Request for Change (RfC) All change requests must be submitted using the ANS Request for Change Form (RfC). Appendix K contains a copy of our RfC form. Alternatively, the latest templates can be found at the following web address: www.ansgroup.co.uk/ms-documents. Upon receiving the RfC an ANS Technical Analyst will evaluate the form and determine the nature of the change before confirming with the requester. Once accepted, Standard Changes will be put forward for scheduling whilst rmal changes will be submitted for SME review before CAB approval. Page 9 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

Impact on Service High MANAGED SERVICES HANDBOOK Please note that an incomplete RfC will be rejected by the Service Desk along with an explanation as to what is missing and further details of any actions needed to be taken before re-submission. Please refer to Appendix F for full details of the ANS Change Workflow. 6.2 Standard Changes Standard Changes are pre-approved changes that have been through the full Change Management Process, including Change Advisory Board (CAB) approval at least once. Standard Changes are added to the Standard Changes list and can be implemented without requiring approval from the CAB. Pease see Appendix L for a full list of ANS approved Standard Changes. Alternatively, please visit www.ansgroup.co.uk/ms-documents for the latest list. 6.3 Emergency Changes ANS classifies an Emergency Change as a Change required in order to resolve or implement a tactical workaround for a P1 incident. All Emergency Changes are subject to approval by both the ANS Emergency CAB and the customer before implementation. An example of an Emergency Change would be if the Operating System on a Virtual Machine has been corrupted and a replacement Virtual Machine needs to be re-provisioned/restored immediately in order to resolve a P1 Incident. Please refer to Appendix G for details of the ANS Emergency Change flow. 6.4 rmal Changes rmal Changes are all Changes that are not classified as Standard or Emergency. Once logged, all rmal Changes are assessed against the following risk matrix and assigned a CR ranking: Significant 3 CR3 Major 2 CR2 Critical 1 CR1 Page 10 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

Low Medium MANAGED SERVICES HANDBOOK Minor 4 CR4 Significant 3 CR3 Major 2 CR2 Candidate for Standardisation 5 CR5 Minor 4 CR4 Significant 3 CR3 Low Medium High Probability of Negative Impact Until Change is Successfully Completed Once assessed, the change will then be submitted for further technical review by an ANS Subject Matter Expert (SME) before submission to CAB. rmal Changes will not be implemented until they have been reviewed and approved by the ANS CAB. Please note that a rmal Change may be added to the Standard Changes list if it is appropriate and the CAB approves it. 6.5 Change Advisory Board (CAB) The ANS Change Advisory Board (CAB) convenes each Tuesday and Thursday during normal business hours. The function of the CAB is to: Review and approve or reject all rmal Change requests logged since the last CAB meeting. Review all rmal Changes implemented since the last CAB meeting. Review all failed or rejected changes since the last CAB meeting. Review the list of Standard Changes and make changes as needed. 6.6 Emergency Change Advisory Board (ECAB) The Emergency CAB is available 24x7 and convenes as soon as an Emergency Change request is raised. A Named Contact from the customers business must also approve all Emergency Changes before implementation. Once approved, the Emergency Change will be implemented as soon as it is possible and safe to do so. 6.7 CAB Approval and Rejection of Changes If the CAB approves the Change, they will inform the ANS Technical Analyst who logged the RfC that it can proceed. If the CAB rejects the RfC, they will provide reasons and further actions Page 11 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

for the ANS Technical Analyst to communicate to the change originator. The Change should then be re-submitted and will be reviewed at the next CAB meeting. 7. Service Management ANS Group adheres to a robust Service Management process, including but not limited to the following: 7.1 Service Review Service Review documents are either sent or presented to customers to detail the service metrics of the Operational Service during a given period. These metrics include: Incident/Problem and Change reporting Trend Analysis Utilisation statistics Capacity reporting/management (where applicable) Release reporting/management (where applicable) Performance statistics (where applicable) Vendor incident breakdown Quality Issues SLA management and measurement 8. Customer Responsibilities Depending on your level of service from ANS there are some requirements for the maintenance and care for your environment, and guidelines for the term of your service. 8.1 Maintenance and Care The guidelines for the term of your service include, but are not limited to, the following: You must have an established 1st line support function that may be validated by ANS. You must have an appropriately skilled technical representative available while an Incident is being managed. Outside rmal Business Hours you must undertake appropriate triage methods to ascertain whether an Incident is of P1 status before logging the Incident. You must undertake an initial impact assessment before logging the Incident with ANS. This assessment is to include: o Affected Services o Business Impact o Number & type of users affected o Recent changes on affected infrastructure (regardless of perceived impact) You must provide ANS with full administrative to all services outlined in the impact assessment and any subsequently identified services. You must ensure that all Customer Supported Assets are appropriately licenced. You are responsible for completing the RfC Form in accordance with the Change Management Process. Page 12 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

You are responsible for ensuring that valid backups are taken of your environment and where necessary the configuration repository. These backups should be available should the need arise to reinstate configuration on an asset within the demarcation zone. 8.2 Maintenance Windows All notifications should be sent to scheduled.maintenance@ansgroup.co.uk and should utilise the outage notification form that can be found on our website: www.ansgroup.co.uk/msdocuments. Failure to do so may result in additional service charges. Please consult the ANS Terms and Conditions for ANS scheduled maintenance details: http://www.ansgroup.co.uk/files/pdf/ansgrouptc.pdf 8.3 Exclusions from ANS Managed service Exclusions from ANS Managed Service include, but are not limited to: Issues resulting from misconfiguration by Customer Employed persons. Failures in maintenance/administration by Customer Employed persons. Incidents arising from lack of training of Customer Employed persons. Data restoration caused by any Unauthorised Change. End user support or technical advice to any persons not listed as a Named Contact. 9. Enhanced Monitoring and Event Management The ANS Enhanced Monitoring System is used for monitoring our customers infrastructure from the Managed Services Network Operations Centre (NOC) within our Head Office located in Manchester. This system is built on a number of technologies using our wealth of knowledge and experience to provide fast and efficient processing of all alerts, and is combined with built-in call-home features that alert us directly from your solution. Our Enhanced Monitoring System has been designed and approved by our own Subject Matter Experts (SME s), who hold high-level accreditations in our core technology areas: NCIE, CCIE, CCIA, VCAP, MCSE and MVP. For details of the ANS Event Management process please see Appendix E. 9.1 Enhanced Monitoring System ANS may install either a physical or virtual probe server onsite as part of your Managed Service. These probes connect back to the ANS Managed Services (NOC) using a secure encrypted connection, which allows for the delivery of monitoring information back to our servers. This information is then fed through ANS custom filters, and Events are created via rules and agreed thresholds. These Events can be in the form of an email or a telephone call and are displayed on the management consoles for viewing by our Technical Analysts. Page 13 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

9.2 Event types Informational, Warnings and Critical Each Event is categorised as one of the three following types: Informational Informational Events include confirmation of a batch job or backup completion. This information is fed in to the NOC s daily checks and on-going healthcare for managed systems. Warning Warning Events include systems or processes that may have reached a predefined warning threshold, such as Storage Volume capacity reaching 80%. The NOC will then review and assess if any further preventative action is required in order to mitigate possible system impact. Critical Critical Events include a System or Process that has either reached a predefined critical warning level such as a Storage Volume capacity reaching 90%, or a System, Service or Device down. The NOC would first assess to ensure the Event is related to a genuine alert before initiating the Incident Management process. Events - dependent on type and criticality - are routed to the NOC via e-mail and automated updates to the ANS Enhanced Monitoring system/wallboards. Critical Events are also raised via an automated phone call to an appropriately skilled Technical Analyst 24x7x365. 10. Release Management 10.1 Release Management ANS follows a strict Release Management policy, whereby all new software releases for our supported products are submitted through our internal release testing process. Only on successful completion of this testing process are releases or patches classified as ANS recommended or Safe harbour. This information is then fed in to the Service Management team to highlight any exposures or recommended upgrades to our customer base. Please refer to Appendix H for further details on the ANS Release Management Workflow. 10.2 OS Patch Management As part of the on-boarding of a new Fully Managed OS Service, ANS will endeavour to agree a process that best suits the customer s needs and requirements for OS Patching depending on various factors, such as: Frequency Deployment technology such as WSUS/SCCM Level of testing UAT required Types of patches to be deployed by ANS Once agreed, this information forms the basis of a Document of Understanding (DoU) between ANS and the customer. An example of a standard patch process is illustrated in Appendix I. Page 14 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

11. Additional Service Charges All services may be subject to Additional Service Charges if outside of the scope of your Service Definition and/or SLA: Service rmal Business Hours Out of Hours Daily Rate Daily Rate (bank holidays and weekends) Charge 250 per hour 450 per hour 1200 plus expenses 2400 plus expenses Below are examples where Additional Service Charges will occur, including but not limited to: rmal Changes (subject to scope of contract) Project Work Customer Cause o Configuration changes not verified by ANS CAB of any supported assets that subsequently causes an outage/incident to be logged o Unauthorised change of any supported Asset of a fully managed service o Remediation of supported assets resulting from any power outage General Exclusions o Logging any non-p1 call Out of Hours (unless covered within the customers service definition document) o Standard contract customers logging non-hardware P1 calls Out of Hours o Deviation from the agreed scheduled maintenance window process o Remediation of security breaches o Remediation of customer caused incidents o Remediation of unauthorised changes by the Customer Please refer to your SDD for full detail of inclusive services. Page 15 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

12. APPENDIX A ANS Escalation Procedure Level Contact Definition Name Contact Roles/Responsibilities 1 Service Desk Technical Analyst Incident is with the Service Desk. Service Desk +44 (0)161 227 1010 All tasks involved with incident management. 2 3 Service Desk Team Leader Service Desk Manager/ Service Manager Incident has been escalated to Team Leader. Team Leader to monitor incident to resolution, including all P1 Incidents. Incident has been escalated to Service Manager or Service Desk Manager. Infrastructure Data Centre i3 Infrastructure Network Infrastructure Applications Service Manager/Steve Breen (Service Desk Manager) +44 (0)161 227 1010 Can allocate additional resource and/or equipment. +44 (0)161 227 1000/+44 (0)161 227 1010 Prioritisation/re- allocation of equipment and/or additional resource. Help to manage stakeholder communication. 4 Head of Service Delivery Head of Service Delivery notified. Chris Hodgson +44 (0)161 227 1000 Will provide assistance in ensuring that all avenues are being investigated to help resolution/ Will manage Key Stakeholder communication. 5 6 Managed Services Director Managing Director Managed Services Director is notified to take appropriate action. ANS Group Managing Director is alerted. Paul Shannon +44 (0)161 227 1000 Empowered to use all resources available to ANS Group. Will discuss incident with ANS Managing Director. Ensures that all other parties of Paul Sweeney +44 (0)161 227 1000 escalation path have acted as expected and utilised all available means to resolve the Incident. Escalations are 24/7; however, steps 3 & 4 are replaced with the Duty Manager outside of rmal Business Hours. Escalations are automated via ANS ITSM system but can be manually triggered as required. Escalation paths may be expedited depending on Incident priority. Page 16 of 32, Issue : 2 Issue Date: 23/10/2013: CLASSIFIED: PUBLIC

13. APPENDIX B ANS Incident Management Workflow 1. Start 2. Check contact and contract details CMS SKMS 3. Invalid contact name or support not contractually covered? 4. Inform Team Leader and Service Management 5. Service Management engages Contracts team to process 6. Invalid contact name? 7. Reply to user explaining authorised contacts policy 10. Collect information, record, categorise and perform impact assessment 9. Mark as chargeable 8. Chargeable status agreed with customer? 12. Major Incident Process 11. Classified as a P1? 13. Assign to Resolver Group 14. Assign to Technical Analyst 15. Mark as WIP 16. Investigation and diagnosis 17. Does this relate to an existing open Problem? 18. Associate Incident to existing Problem and notify Problem assignee 30. Re-evaluate impact and urgency and adjust Priority if required KEDB CMS 19. Is the same underlying cause already generating or likely to generate related incidents? 20. Problem Management Process 28. Escalation to vendor required / available? 29. Initiate Vendor Support 21. Workaround needed/ available? 22. Implement Workaround 23. Re-evaluate impact and urgency and adjust Priority if required 24. Change(s) Required? 25. Change Management Process 27. Assign to alternate resolver Group / SME 26. Resolution implemented? 31. Mark as resolved 32. Resolution / implementation confirmed by customer? 33. Close Page 17 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

14. APPENDIX C ANS Major Incident Management Workflow 1. Start 2. Assign incident to available SME to begin immediate investigation and mark as WIP 3. Begin a summary timeline log and ensure all communication events and technical milestones are recorded 4. Email the escalation distribution group with incident summary details and continue emails for subsequent milestone updates 6. The On-Call Duty Manager assumes the role of Incident Manager. Telephone them and give full incident details and impact analysis (actual and potential) 5. Out of hours support authorised? 8. The Resolver Group Team Leader assumes the role of Incident Manager. Ensure that they are aware of full incident details and impact analysis (actual and potential) 10. The Incident Manager establishes contact with the customer and agrees the communication schedule (hourly updates unless otherwise agreed). 9. The Incident Manager ensures that Service Desk Manager and Service Manager are aware of the incident impact (actual and potential) 11. Investigation and diagnosis 25. Re-evaluate impact and urgency and adjust Priority if required 12. Does this relate to an existing open Problem? 13. Associate Incident to existing Problem and notify Problem assignee KEDB CMS 14. Is the same underlying cause already generating or likely to generate related incidents? 15. Problem Management Process 23. Escalation to vendor required / available? 24. Initiate Vendor Support 16. Workaround needed/ available? 17. Implement Workaround 18. Re-evaluate impact and urgency and adjust Priority if required 19. Change(s) Required? 20. Change Management Process 22. Assign to Technical (PS) SME 21. Resolution implemented? 26. Mark as resolved 27. Resolution confirmed by customer? 28. Conduct Major Incident review and Root Cause Analysis (RCA) 29. Team Leader authorises RCA summary to be sent to customer. 30. RCA Summary (mandatory) 33. SIP (if required) 31. Depending upon incident circumstances, the Service Manager may agree to deliver a Service Disruption Report and possibly initiate a Service Improvement Plan. 32. SDR (if required) 34. End Page 18 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

15. APPENDIX D ANS Problem Management Workflow 1. Start 2. Create new Problem record, categorise, and perform impact assessment 4. Ensure logging and communications are consistent with the Major Incident Process and strictly adhered to through to problem resolution 3. Is this a PR1? 5. Assign to Resolver Group 18. Re-evaluate impact and urgency and adjust Priority if required 6. Assign to SME 7. Mark as WIP 8. Problem investigation and diagnosis 11. Incident Management Processes KEDB CMS 9. Workaround discovered/ available? 10. Ensure all workarounds are documented in the KEDB and available to Incident technician(s) 16. Escalation to vendor required / available? 17. Initiate Vendor Support 12. Change(s) Required? 13. Change Management Process 15. Assign to Technical (PS) 14. Has investigation led to a resolution? 19. Mark as resolved 20. Resolution confirmed by customer? 21. Is this a PR1? 22. Conduct Major Incident review and Root Cause Analysis (RCA) 23. Team Leader authorises RCA summary to be sent to customer. 24. RCA Summary (mandatory) 27. SIP (if required) 25. Depending upon incident circumstances, the Service Manager may agree to deliver a Service Disruption Report and possibly initiate a Service Improvement Plan. 26. SDR (if required) 28. End Page 19 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

16. APPENDIX E ANS Event Management Workflow 1. Start 2. Critical Event? 3. Initiate Callout 4. Investigate 5. Incident Required? 8. False Positive 9. Email Service Desk and update Wallboard/Portal 6. Trigger Incident Management Process 10. Service Desk Investigate 11. Incident Required (Warning)? 14. Trigger Problem Management Process 7. Close Event 12. Problem Required? (Recurring Incident) 13. Raise P3 Pro-Active Problem 15. Acknowledge (Information Only) Page 20 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

17. APPENDIX F ANS Change Management Workflow Front Line Service Manager CAB Implementer 5. Logged in Sostenuto 6. Check Standard Change List Standard 7. Standard or rmal 16. Initiate Outage tification Sub Process & Schedule Downtime 28. Close Change in Sostenuto. Initiate Mini Project Sub Process 15. Downtime Required? 14. Approved? 13. CAB Meeting 11. Financial Approval Required? 17. Implementation 21. Give reasons and possible solutions to the change originator 9. rmal Record 10. 8. Implementation Tech Specialist Within Scope? steps and Roll Tech Vet back plan 12. Financial Approval Received? 18. Change Successful? 24. Roll back? 26. Initiate Incident Management Process Y 19. Update Technical Documentation 20. Close Incident in Sostenuto 25. Invoke Roll back plan 27. New Change required? Change Originator 1. Change Request 2. Emergency? 4. RfC 3. Emergency Change Process 23. Re-assess and resubmit Change t Rejected 22. Confirm Rejection? Rejected Page 21 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

18. Appendix G - Emergency Change Front Line ECAB Service Manager Implementer 3. Customer & ECAB Approval (Including Commercials) 2. Emergency Change logged in Sostenuto 4. Implement Change 5. Change Successful? 10. Give reasons and possible solutions to the change originator 6. Resolve Problem / Incident 10. Roll back? 12. Initiate Incident Management Process 7. Review at next CAB 11. Invoke Roll back plan 13. New Change required? 8. Update Documentation 9. Close Problem in Sostenuto Change Originator 1. Initiate Emergency Change 11. Resubmit amended change Page 22 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

19. Appendix H Release Management Start New release received from Vendor Submit to ANS UAT testing Accepted by ANS Quality team? N Raise new known error via Problem Management Process Close Y Update Service Catalogue and Safe Harbour releases Pass to Service Management for Customer suitability and comms Update CMDB Engaged Change Management and implement Page 23 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

20. Appendix I OS Patch Management- Example Start Emergency Patch? Y Incident Management process ANS Action N Patch Tuesday release from Microsoft Customer Action ANS upload all patches (excluding Service Packs) and apply to all managed servers within 5 days ANS reboot Tier 0 Severs at +5 days Customer Test Issues identified? N ANS Reboot Tier 1 Servers +10 days Customer Test Issues identified? Y Y Y Restore and stop process. N ANS Reboot Tier 2 Servers +15 days Customer Test Issues identified? Close Page 24 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

21. APPENDIX J ANS Managed Service Offerings Page 25 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

22. APPENDIX K ANS Request for Change (RfC) Form Instructions: Please complete as much of this form as possible and email to servicedesk@ansgroup.co.uk Logging Details Organisation Name: Change Requested By (Your Name): Job Title: Phone: Email: Date Change Submitted: CR Number (ANS Use Only): Authorisation Details Customer Approval Contact: Customer Approval Status: Customer Approval tes: ANS Reviewer: ANS Review Status: ANS Review tes: Change Details Change Title: Change Impact (Low, Medium, High): Change Urgency (Low, Medium, High): Details of Change Reason for Change: Systems Changed: Other Information Any other information that will help the approver make a qualified decision: Page 26 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

*FOR ANS USE ONLY* Implementation Details Implementation Steps: Implementation Date: Estimated Time to implement: Estimated Downtime: Risk Rating: Impact and Potential Risks: Testing Steps: Back Out plan Please refer to www.ansgroup.co.uk/ms-documents for the latest RfC template. Page 27 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

23. Appendix L Standard Change list 23.1 23.2 General Changes Type of Change Examples Exceptions Vendor Hardware replacement Fans, PSUs, disks System Board replacements or any replacement that leads to downtime; Replacements that require a significant amount of reconfiguration Requests for Information Capacity/ performance reports Full health checks or anything that will take longer than 1 hour Remove devices from monitoring upon request of a customer Cannot remove a SCOM gateway server or Monitoring Probe server from systems 23.3 I-Apps Changes Type of Change Examples Exceptions New users New starters > 9 users requested at one time Delete users Delete user who has left > 9 users requested at one time Edit user attributes and profile settings Name changes; changes to contact details > 9 users requested at one time New mailbox New Exchange user > 9 users requested at one time Delete mailbox Remove Exchange User > 9 users requested at one time Edit mailbox New email address alias > 9 users requested at one time Edit group membership Edit distribution list > 9 users requested at one time Edit permissions User requires access to files > 9 users requested at one time Page 28 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

Resize Windows 2008 disks Exchange volume is being resized Where there isn t enough capacity in the containing datastore. National Cloud shared platform customers. Add network printer objects to AD Quest user sync Publish new Desktop to a XenApp server Disable Java update service Rename Virtual Machine Edit Citrix timeout value Import PST file Create new Exchange contact Recreate user profile Add shortcut to published desktop Change printer port Delete Exchange distribution list New Exchange distribution Group New network printer is added Used to facilitate user migrations Increase in user base requires more desktop resources Customer has requested for archive mail to be restored Contact for external address is needed in Exchange Mailbox User profile is corrupt and user cannot login User required link on their Citrix Desktop New printer Drivers for a Citrix environment are to be classified a rmal Change. > 9 users requested at one time More than 3 servers Where importing the PST would breach any mailbox quotas. Exchange 2007 or above only 23.4 Infrastructure Changes Type of Change Examples Exceptions New Virtual Machine from template Mount SMVI snapshot and restore a file Resize VMware Datastore Mount SMVI snapshot to restore a file Over 9 VMs or where there is not enough resource or capacity. VMs that deviate from template should be approved by Change & provisioning manager Where there isn t enough capacity in the containing volume. Page 29 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

National Cloud shared platform customers Update Autosupport settings Update UCS call home settings New user quotas Restrict the amount of NetApp storage a user can access Request to monitor volume capacity Creating new DFM alarms and reports Edit time sources Change of NTP details Where a reboot or loss of service is required New NetApp volume or LUN Where the aggregate does not have enough space Resize NetApp volumes and LUNs Creating NetApp CIFS Shares Creating NetApp NFS exports Edit Snapshot schedule Enable SSL and SSH in ONTAP Assign replacement disks to NetApp controller Install or update NetApp System Manager New disk (vmdk) for VM Access to console via SSL National Cloud shared platform customers Where the aggregate does not have enough space National Cloud shared platform customers Where the aggregate does not have enough space National Cloud shared platform customers Where the aggregate does not have enough space National Cloud shared platform customers Where the volume does not have enough space to accommodate further snapshots Where there is not enough space in the underlying datastore Page 30 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

Delete NetApp Volume snapshot Delete VM snapshots Where the customer has not agreed to delete the snapshots DFM, SnapManager, SnapMirror, SnapVault, VSC or Commvault created backups are excluded. This change only applies to snapshots that have been manually created or created by the volumes snapshot schedule (e.g. hourly.0, daily.1, etc.) Where the customer has not agreed to delete the snapshots 23.5 Network Device Changes Type of Change Examples Exceptions New Cisco ASA ACL rule Create rule to allow smtp access to a server Cisco ASA ACL rule change New NAT statements Edit external addresses access to ports on server Any rule that compromises security best practices Any rule that compromises security best practices Any rule that compromises security best practices Edit NAT statements Any rule that compromises security best practices Add/Remove Cisco time based license to ASA Update cisco IPS auto/cisco.com update server IP address Large number of users working from home requires more user licenses temporarily Page 31 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC

24. Appendix M Service Level Management Service requirements Define and document future requirements and targets Service Portfolio Agree and document SLR s Service Catalogue Define and document current requirements and targets Agree and document SLA s Support Teams Provision of services Proactive prevention of service failures. Quality improvements and risk reduction OLA s Monitor and measure against SLA Supplier Management Review SLA s service scope and underpinning agreements Service Review Meeting UC s Service Improvement Plan Partners / Suppliers Periodic review of SLR s and SLAs Page 32 of 32, Issue : xx Issue Date: 04/10/2013: CLASSIFIED: CONFIDENTIAL,INTERNAL ETC