1. Customer Engagement Workshop IT Service Continuity Phoenix, Farnborough 17 th June 2015 Paul Gant, Head of BCM Assurance David Davies, BCM Assurance Consultant

2. Agenda 11:00 Registration, refreshments and networking 11:30 Why get fit, anyway? 11:50 Fictitious live incident 12:10 Post incident review 12:30 Steps to success 12:45 Phoenix ITSC service set 12:50 Questions & answers 13:00 Lunch, tours, event close

3. Introducing our BCM Assurance Consultant… David Davies: 12 years continuity management experience, over 70 clients across multiple sectors Unique experience: extensive consultancy, IT service continuity management (IBM), business continuity management (Barclaycard) Experience of implementing Business Continuity Standard and Information Security Standard Works to demystify the subject Delivers practical advice

4. Why get fit, anyway?

5. Introducing BCM Assurance – your personal trainers

6. What if?

7. Real Recovery (Invocations) is like a Battle YOUR ENEMIES (Lack of) time. You can’t recover what you haven’t backed up. You can’t upgrade recovery technology during an invocation. YOUR FRIENDS Phoenix. Your preparation.

8. What does “Preparation” involve? It’s not just about the technology! But aren’t policies, analysis, plans and reports only there to satisfy to auditor? Is there any rhyme or reason to them?

9. PrioritiesDependenciesPlansTestingMaintenance IT Service Continuity Management

10. 1. What’s needed first? PrioritiesDependenciesPlansTestingMaintenance

11. 2. What rests on what? 3 DependenciesPlansTestingMaintenancePriorities

12. 3. Make a plan DependenciesPlansTestingMaintenancePriorities

13. 4. See if it works DependenciesPlansTestingMaintenancePriorities

14. 5. Keep it up-to-date PrioritiesDependenciesPlansTestingMaintenance

15. Phoenix Standby Reasons

16. Phoenix Invocation Reasons

18. The reccurring dangers that we see IT recovery requirements haven’t been agreed with the business (through a BIA). IT recovery strategy isn’t joined up (i.e. a full end to end solution isn’t there). Strategy isn’t supported by plans and isn’t tested rigorously enough (resulting in inefficiencies and failures during actual recovery).

19. Fictitious Live Incident (Why have a personal trainer to help you?)

20. Warehouse and second server room (ground floor) Backup SAN and tapes Offices and Server room 2 nd (top) floor CRITICAL SYSTEMS: Recovery Time Objective 24 hours Recovery Point Objective 24 hours (disk to disk daily) NON CRITICAL SYSTEMS: Recovery Time Objective 5 days Recovery Point Objective 1 day (local tape) and 7 day (offsite tape)

21. Warehouse and second server room (ground floor) Backup SAN and tapes Offices and Server room 2 nd (top) floor 1 gbps CRITICAL SYSTEMS: Recovery Time Objective 24 hours Recovery Point Objective 24 hours (disk to disk daily) NON CRITICAL SYSTEMS: Recovery Time Objective 5 days Recovery Point Objective 1 day (local tape) and 7 day (offsite tape)

22. 08:07 Fire Warehouse and second server room (ground floor) Backup SAN and tapes Offices and Server room 2 nd (top) floor CRITICAL SYSTEMS: Recovery Time Objective 24 hours Recovery Point Objective 24 hours (disk to disk daily) NON CRITICAL SYSTEMS: Recovery Time Objective 5 days Recovery Point Objective 1 day (local tape) and 7 day (offsite tape)

23. 12:15 Servers onsite Warehouse and second server room (ground floor) Backup SAN and tapes Offices and Server room 2 nd (top) floor CRITICAL SYSTEMS: Recovery Time Objective 24 hours Recovery Point Objective 24 hours (disk to disk daily) NON CRITICAL SYSTEMS: Recovery Time Objective 5 days Recovery Point Objective 1 day (local tape) and 7 day (offsite tape) 08:07 Fire

24. Warehouse and second server room (ground floor) Backup SAN and tapes Offices and Server room 2 nd (top) floor CRITICAL SYSTEMS: Recovery Time Objective 24 hours Recovery Point Objective 24 hours (disk to disk daily) NON CRITICAL SYSTEMS: Recovery Time Objective 5 days Recovery Point Objective 1 day (local tape) and 7 day (offsite tape) 12:15 Servers onsite 08:07 Fire 12:45 Exec Report

25. Warehouse and second server room (ground floor) Backup SAN and tapes Offices and Server room 2 nd (top) floor 12:15 Servers onsite 08:07 Fire 12:45 Exec Report CRITICAL SYSTEMS: Recovery Time Objective 24 hours Recovery Point Objective 24 hours (disk to disk daily) NON CRITICAL SYSTEMS: Recovery Time Objective 5 days Recovery Point Objective 1 day (local tape) and 7 day (offsite tape) 13:15 Start recovery

26. 12:15 Servers onsite 08:07 Fire 12:45 Exec Report 13:15 Start recovery

27. 12:15 Servers onsite 08:07 Fire 12:45 Exec Report 13:15 Start recovery 09:30 Server recovered?

28. 12:15 Servers onsite 08:07 Fire 12:45 Exec Report 13:15 Start recovery 09:30 Server recovered? 11:45 Recovery stalled

29. Post Incident Review (What are the consequences of being unfit?)

30. Post Incident Review What went well? (Where were they fit?) what went badly? (Where were they unfit?) What could the IT manager have done differently during the recovery? What could the IT manager have done differently before the recovery?

31. IT Service Continuity Issues Have you experienced any of the issues raised? Difficulty in getting board engagement. No business requirements for IT recovery (i.e. not BIA). Single points of failure in key skills sets. Lack of recovery documentation (perhaps no spare time to write it?) Lack of formal testing and test reporting. Any other issues?

32. The Barriers and Results What’s stopping you / stopped you from making changes? What would happen if changes aren’t made and you invoke? What would happen if you do make the changes?

33. Steps to Success (How to become IT service continuity fit.)

34. What if?

35. The Steps to Successful IT Service Continuity 1. Engagement and sponsorship at a strategic level. 2. Balance between the technology and ITSC management. 3. Do all of ITSC, and run it as a repeating programme.

36. 1. Strategy: Talk the Language of the Business

38. 1. Strategy: Engage with the Executive Team Does the Executive Team know: What are the impacts if IT fails? What are the risks associated with IT failure? What is the RTO and RPO of services – and what these terms mean. What is the recovery and hand back process?

39. 2. Balance Technology with ITSC Management

40. 3. Do all of the Programme Steps, and Repeat PrioritiesDependenciesPlansTestingMaintenance

41. What if?

42. Trap 1: The Scope Trap

43. Trap 2: The Audit Trap

44. Trap 3: The Importance and Urgency Trap

45. Trap 4: The Gambler’s (or Optimist’s) Trap

46. Trap 5: The Hero Trap

47. Phoenix ITSC Services

48. ITSC is a management system… Department and supplier recovery requirements BIA IT recovery requirements BC Strategy ITSC Strategy Plans Test it Repeat! Business Continuity Management IT Service Continuity Management

49. Where does ITSC fit in? Tech specialist Technology skill level Governance / documentation skill level ITSC consultant IT manager IT director

50. Managed recovery Scenario exercise ITSC services BIA IT recovery gap analysis IT Service Continuity plan IT recovery test management Technical recovery plans Current State Assessment

51. BIA (Business Impact Analysis)

52. Current State Assessment

53. IT Service Continuity Plan

54. Technical Recovery Plans

55. Any Questions?

56. Thank you for participating. Lunch is now ready. Would you like a tour or a meeting?