Tutorials, TU-13-8386 R. Witty
Research Note 15 June 2001
Integrating BCP Into the IT Project Life Cycle To maintain customer confidence and financial stability in the event of a disaster, BCP must be addressed at the beginning of an IT project. Here, Gartner describes how BCP can be integrated into the IT project life cycle.
Core Topic Software Infrastructure: Disaster Recovery and Business Resumption Planning Key Issue What strategies should organizations employ to provide business process protection in the event of a disaster?
Executives often balk at the expense of IT projects, and deferring investment in business continuity planning (BCP) may make them more palatable. Those enterprises that have scrambled to get e-business initiatives up and running to keep up with the competition and to meet customers’ expectations have viewed BCP as a delay, if it is considered at all. Often, on-site redundancy and day-to-day availability requirements are considered; rarely is a multicomponent outage or a full site outage addressed during the project. This level of planning is often done after a system has been designed or implemented. Bad publicity and loss of customer confidence can cost an enterprise far more in the long run than the extra time and resources spent on planning for BCP from the beginning of the IT project. We recommend that enterprises integrate BCP into the eight phases of the IT project life cycle (PLC): 1.
Business requirements
2.
System architecture
3.
System design
4.
Construction
5.
Testing
6.
Implementation
7.
Post-implementation
8.
Retirement
The deliverables from each phase are used as input to each subsequent phase. The activities of each phase are executed by the members of the IT project team — depending on the goal of Gartner Entire contents © 2001 by Gartner, Inc. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.
each phase, a subset or full contingent of participants are required. See Figure 1 for a description of each participant’s responsibilities. Figure 1 BCP Roles and Responsibilities • Defines BCP requirements of the system, including recovery time objective (RTO), recovery point objective (RPO) and service-level agreement requirements related to availability such as Information Owner peak production times on a daily, weekly, monthly, quarterly or annual basis • Approves BCP expenditures and reviews • Approves the BCP test results being in compliance with the stated requirements Infrastructure and • Designs/implements all business continuity components of the system based on the Application Development requirements of the information owner, including load balancing, data replication, rollback (IAD) Team procedures, RPO points within the application and redundant equipment • The team is comprised of all IT constituencies responsible for bringing the new system to production — software development, hardware, database, storage, middleware, networking, telecommunications, operations, etc. • Coordinates all activities related to the creation, updating and testing of the existing business Business continuity plan caused by the introduction of a new system to ensure that the business can Continuity/Disaster recover from an event that renders its production environment inoperable for an extended Recovery Coordinator(s) period of time • Reports to the information owner and senior management as to the status of the business continuity program • The two roles are often performed by different personnel, with the business continuity coordinator reporting into the business/operational unit, and the disaster recovery coordinator reporting into IT • Consults on the IT project regarding the interpretation and implementation options of the enterprisewide information security and business continuity policies as they relate to a security Cyber-Incident Response breach impacting the availability and continuity of the system, including assessment, tracking Team (CIRT) and investigation activities, as well as the procedures that need to be followed in such an event Business Continuity/Disaster Recovery Team(s) • Tests the business continuity and disaster recovery solutions for the system • Executes the business continuity/disaster recovery plans during an event • Responsible for the formal turnover to production of the system(s), and rollback to the existing Change Management environment if a problem is encountered during the turnover of the new system • Acts as an independent check on the business' adherence to the enterprisewide information IT/EDP Audit security and business continuity policies Source: Gartner Research
This Research Note is written from an IT project perspective, and therefore does not address all BCP activities, such as the creation of a business continuity policy, business continuity organization, crisis management team or personnel evacuation/management plans. For a model that addresses all BCP activities, refer to the Business Continuity Planning Model by DRJ.com at www.drj.com. However, all such components should be reviewed and updated if required to meet the business continuity requirements of the systems being developed by the IT project. Business Requirements: The goal of the first phase of the PLC is for business management to identify the high-level, business-
Copyright 2001
TU-13-8386 15 June 2001
2
related continuity requirements for the new IT system(s). Activities to be completed during this first PLC phase include: • Business impact analysis (BIA) • Risk analysis (RA) for the business as a result of using the new system(s) • The recovery time objective (RTO) • Recovery point objective (RPO) • A review of the impact of the new system(s) on existing business processes and systems. This review will ensure that the business continuity requirements can be supported throughout the entire processing stream. Changes may be required in supporting or interdependent business processes and systems that will mean additional design, development, implementation and funding not anticipated when viewed only from the new system(s) perspective. In an example of business continuity requirements, the system will be used by front-office personnel such as traders and trader assistants for trade entry, back-office operations for execution and risk management for credit and risk assessment. It must be available from Sunday evening 7 p.m. EST through Friday 9 p.m. EST, because the trading book is global. The system must be available within one hour for a single component outage and within four hours of an outage, with no loss of data, for a multicomponent or site outage; therefore, the system must be designed for no single point of failure. In addition to business management, often referred to as the information owner, other participants in BCP for this first PLC phase include: the Infrastructure and Application Development (IAD) team, the business continuity/disaster recovery coordinator(s), the cyber-incident response team (CIRT) and the audit department. System Architecture: The goal of the second phase of the PLC is to establish a system and business process architecture that supports the business continuity requirements for the new system(s), interdependent systems and associated business processes. In the second phase of the PLC, the following activities are completed: • Scenario(s) under which the plan will be executed • Business continuity strategy alternatives development • Cost/benefit analysis of each alternative • Selection of the best business continuity strategy
Copyright 2001
TU-13-8386 15 June 2001
3
Participants in the second PLC phase include the information owner, the IAD team, IT operations, the business continuity/disaster recovery coordinator(s) and the CIRT. System Design: The third phase of the PLC will draw upon all participants of the BCP process with the goal of developing a detailed design and set of specifications for the system(s) in support of the business continuity requirements for the new system(s), as well as supporting/interdependent business processes and systems. The recovery of the system(s) after the emergency event, as well as its restoration to the production site, must be considered. Activities to be completed in this third PLC phase include: • Business continuity/disaster recovery team(s)/responsibilities identification, including the party responsible for maintaining the business continuity plan itself • Technical components/architecture design • Business processes design • Escalation, notification and plan activation strategy • Vital records/off-site storage program • High-level test strategy Construction: In this step, the enterprise builds the disaster recovery and business continuity plans and technical components in support of the business continuity requirements. Activities to be completed in this fourth PLC phase include: • Emergency response procedures • Personnel call trees • Technical disaster recovery infrastructure, including systems and telecommunications • Recovery and restoration procedures • Vendor selection and contracts for purchased recovery services (e.g., outsourced recovery service providers or offsite storage) • Detailed business continuity test plan All business continuity participants should be involved in the activities of this fourth PLC phase. Testing: The fifth PLC phase is one of the most important phases in the overall IT project — ensuring that what was designed and built meets the RTO/RPO as defined by the business in the first phase. Testing also ensures that the Copyright 2001
TU-13-8386 15 June 2001
4
business continuity/disaster recovery team(s) is trained in the recovery of the system(s). Using the business continuity test plan, activities to be completed in this fifth PLC phase include: • Recovery and restoration procedures walk-through, i.e., a tabletop test • Emergency response procedures execution • Personnel call tree execution • Recovery and restoration procedures execution, where feasible. If the IT project and associated new systems are mission-critical, a complete execution of the business continuity plan may be warranted. If not feasible, then a date must be selected, no more than three months after the implementation date, when the business continuity plans will be tested — separately or as part of a larger business continuity test. • Immediately after the test, a report must be issued to the information owner regarding all areas where the business continuity strategy does not meet the requirements. A plan must be developed that identifies who is responsible for closing the gap, and by when. It must be noted in this report the date when the gap resolution will be tested, if applicable. It is important to consider the impact on customers during the test — you might include them as well as external interdependencies to ensure that the entire business process can be successfully recovered. Implementation: During this sixth PLC phase, change management promotes application software to production, and IT infrastructure personnel implement hardware and telecommunications into the production environment. It is often prudent to perform a second test of the disaster recovery IT infrastructure after implementation, especially when using an outside service provider for IT operations. Maintenance: All major changes to the system(s) must include a review of the business continuity strategy and plans to ensure that they still meet the requirements as defined by the information owner. Such changes must cycle through all BCP activities in each PLC phase through implementation to ensure that the system(s) will be recoverable. Retirement: When the system(s) is no longer required, the takedown of the disaster recovery and business continuity environment must be completed. Activities to be completed in this last PLC phase include:
Copyright 2001
TU-13-8386 15 June 2001
5
• Disablement of the disaster recovery IT infrastructure • Destruction of emergency response procedures, recovery and restoration procedures, and personnel call trees • Cancellation of all vendor contracts • Destruction of off-site storage, according to regulatory retention requirements. Not all off-site storage can be destroyed when no longer needed for current production business processing — those controlled by regulatory agencies such as revenue/tax agencies must be available for restoration purposes in the event of a regulatory or legal dispute. Confer with the legal department to determine the long-term retention requirements for your industry and enterprise. Bottom Line: Enterprises that simply add BCP to system(s) already designed or implemented expose themselves to unnecessary risks ranging from the minor customer annoyance to the loss of revenue from customers going to a competitor to outright stoppage of its business. Enterprises that incorporate BCP into system(s) from the beginning will enjoy a competitive advantage that will manifest itself in fewer disruptions to enterprise operations, and in greater confidence from customers, partners and suppliers.
This research is part of a broader article consisting of a number of contemporaneously produced pieces. See COM-13-6392 on www.gartner.com for an overview of the article.
Copyright 2001
TU-13-8386 15 June 2001
6
