DO YOUR DISASTER RECOVERY TIME OBJECTIVES MEET YOUR BUSINESS REQUIREMENTS?

By Karen Dye, CBCP Global Business Continuity Manager Sun Microsystems, Inc.

DO YOUR DISASTER RECOVERY TIME OBJECTIVES MEET YOUR BUSINESS REQUIREMENTS?

Sun Microsystems, Inc.

If you are an IT disaster recovery manager, you most likely have disaster recovery plans in place that provide for recovery of critical business applications and the systems to support those applications. What processes and criteria were used to determine the recovery time objectives (RTO the time to recover the system after a disaster) and recovery point objectives (RPO time passed since last backup prior to a disaster) for those systems? Do you look at the recovery of the critical business processes or only focus on the recovery of the systems? Do you have a process in place to ensure the synchronization of the recovery objectives of the two perspectives? How often do you confer with your company's Business Continuity Manager? Or do you even know if you have a Business Continuity Manager? In todays business environment, a business application system is entwined with the business process it supports (especially if dependent on a e-business component). This should also hold true for the recovery plans of those systems and processes. When (Note: when, not if) a disaster strikes your company, critical, time-sensitive business processes must continue their operation to ensure your company continues to function as a reliable business. For example, California companies are susceptible to earthquakes and must assume a worst-case scenario where people are injured, freeways are impassable, and the phone service is hindered. Other geographical locations experience other natural disasters, such as hurricanes, tornadoes and floods, which can also impact availability of employees and transportation options. You may have operations outside your current location or country that will continue to produce products or provide services, but what business processes are conducted locally, upon which those other sites are dependent? Business recovery time objectives are usually determined by a business impact analysis. System recovery time objectives are usually defined by the method used and time required to recover the system. When was the last time you analyzed and compared these two for any gaps? Does your company consider RTO and RPO when a new business systems application is designed and/or implemented? Do you ask the impact to RTO and RPO when a major change is proposed? Many companies have system development and/or project management life cycles. Where in that process/methodology do you find your recovery strategy being applied? Best practice has the business impact analysis and application criticality defined in the initial assessment, prior to approval. Recovery strategy will impact the hardware design and dictate data backup solutions. A high availability solution will be more costly than a recovery time objective of several weeks. What risks are you willing to incur for what cost? This is all dependent on the criticality of the application and the business process it supports. The disaster recovery plan also needs to be tested prior to the system being deployed into production. A disaster is an interruption of a system for an unacceptable period of time. A business process may utilize multiple computer systems and platforms. And each business process may have a different unacceptable period of down time. The focus of any recovery plan must be on keeping the business running not keeping the computer running. Are recovery objectives in sync between the business process and the multiple systems and platforms that support the process? Business continuity requirements should be done before the computer requirements are defined. The business owner needs to determine what is an acceptable risk for the business. The business owner should determine the RTO and agree to the resulting cost of the systems implementation to meet that objective. If a project is implementing new computer technology not currently related to a new business application, the business processes that will eventually be dependent on the projects deliverables will determine the recovery requirements. Its helpful to have a decision matrix that describes who has responsibility for approval vs. review and information provider.

DO YOUR DISASTER RECOVERY TIME OBJECTIVES MEET YOUR BUSINESS REQUIREMENTS?

Sun Microsystems, Inc.

Table 1. An example of a decision matrix.

Person Business Sponsor, responsible for business function Technical Architecture Disaster Recovery Manager Business Continuity Manager Application Support Computer Operations

Requested RTO/RPO Information Provider Information Provider Review Review Review Review

Cost of Technical Solution Review Owner Review Review Review Review

Final RTO/RPO and Recovery Plans Owner, final approval and signature Review of plans Review of plans Review of plans Owner of recovery plans

RPOs are determined by the amount of data/transactions that can afford to be lost. Possible RPO tiers are: > Tier A No data loss > Tier B RPO of less than 24 hours > Tier C RPO of last backup (in most cases, will be 24 36 hours) RTOs are usually tiered. Youll need to look at your companys unique requirements as to how many tiers are appropriate for your organization more than five usually becomes unmanageable. An example of four tiers for RTO is: > Tier 1 Fault tolerant virtually no impact to end-user if system goes down. Replication is part of the design of the system/application and usually requires Tier A RPO. > Tier 2 RTO of less than 24 hours. Requires hot standby equipment and usually a Tier B RPO. > Tier 3 RTO of less than 48 hours. Production takes over test and development equipment in the event of a disaster. This usually only applies when a company has a second Data Center, where production runs at one site, with test and development at the other site. > Tier 4 RTO of greater than seven days. Requires acquisition of hardware and restoration of systems. RTO and RPO need to be defined whether you are recovering at your own alternate Data Center or you are recovering at a cold or hot site operated by a third party. Third-party providers now have advanced recovery services that can meet high availability requirements for RTO and RPO. Answers to the following questions addressed to the business owner will assist in determining RTO and RPO: 1. What does this business process use to do its work? 2. What resources (people, skill sets, other tools) are needed for this process to continue to function in a disaster scenario? 3. What vital information flows through this business process, either from another process and/or to another process? What other business processes are dependent on the activities of this process? 4. What activities of the process can be done manually, if needed? What manual work around procedures could be put in place to minimize either the financial or non-financial impacts? 5. What would be the direct financial loss to your company if this business process were not available for 24 hours? One week? Three weeks? How is this loss calculated? What components contribute to this loss? 6. Does this business process have business cycles? Would a significant loss to your company be different at different times of the year? What months are critical? Are there times of the month that are more critical than others? 7. What is the business recovery plan? Are there subject-matter experts outside of the affected area that could process the work if critical employees are not available? 8. What are the negative impacts of the following non-financial concerns if this process does not function for 24 hours? One week? Three weeks?

DO YOUR DISASTER RECOVERY TIME OBJECTIVES MEET YOUR BUSINESS REQUIREMENTS?

Sun Microsystems, Inc.

a. Cash flow (generation of revenue) b. Public image c. Shareholder confidence d. Financial reporting e. Managerial control (for example, approval levels) f. Productivity g. Competitive advantages h. Industry image i. Customer service j. Vendor relations k. Legal/contractual violations l. Regulatory requirements m.Employee morale n. Consumer confidence o. Other 9. For each day of outage, how long will it take to handle the backlog of work, in addition to other daily work, when this process is back in operation? 10.What expenses would be incurred if this process were disrupted? a. Temporary employees b. Emergency purchases (supplies, office machines, etc.) c. Rental/lease of equipment d. Wages paid to idle staff e. Overtime f. Temporary relocation of employees to alternate business recovery location (assume not working from home) 11.What other vulnerabilities and exposure exist with this business process? In most circumstances, the definition of RTO and RPO will be an iterative process. There is no absolute formula. There is also a negotiation process with the business owner to balance the risk with the cost. That is, there may initially be a requirement for a short RTO and RPO. But after weighing the costs of the solution, the business owner may accept a longer RTO and RPO that would be less costly. How much risk are they willing to take for what cost? As with other business continuity plan components, an annual review of the RTO and RPO requirements should be done to capture changes to both the business environment and the systems environment. So if you havent already done so, get to know your counterpart on either the business side or the technology side. Were all in this together. Suns portfolio of Business Continuity solutions all start with a common approach to helping determine appropriate objectives for RTO and RPO. Starting with a Business Continuity Workshop, a targeted Business Impact Analysis, this quickly produces short, medium and longer term plans for establishing the required degree of continuity for each business area and service. For more information about Suns Business Continuity solutions please visit http://sun.com

DO YOUR DISASTER RECOVERY TIME OBJECTIVES MEET YOUR BUSINESS REQUIREMENTS?

sun.com

This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. RESTRICTED RIGHTS: Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g)(2)(6/87) and FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-3(a). DOCUMENTATION IS PROVIDED AS IS AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE DISCLAIMED, EXCEPT TO THE EXTENT THAT SUCH DISCLAIMERS HELD TO BE LEGALLY INVALID.

Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 USA Phone 1-650-960-1300 or 1-800-555-9SUN Web sun.co sun.com
2005 Sun Microsystems, Inc. All rights reserved. Sun, Sun Microsystems and the Sun logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.