Getting Your Business Back

Transcription

1 Getting Your Business Back Pulling Together Business Continuity, Crisis Management and Disaster Recovery Many organizations have a program (or programs) in place to keep operations going (or to resume them as quickly as possible) when faced with a loss or interruption of resources. Whatever these programs are called business continuity, disaster recovery, business resiliency or anything else there seems to be a common thread: the responsibility for them tends to lie in several different (and often uncoordinated) departments. In many cases, the business continuity group reports to the CFO, the Risk Officer, the COO and the IT department. But structure and reporting does not guarantee successful business continuity. With responsibility for business continuity lying in so many places, how do you make it work? This white paper outlines an approach to business continuity that lets you take a group of people with unique and valuable skills and organize them in a collaborative way to create a successful business continuity program. This does not mean that every member of the team is equal to the next. Leadership and accountability are also important parts of a successful business continuity recipe. The approach outlined in this paper is founded on the belief that a business continuity program can only be effective if it s a part of the culture of an organization. Definitions As a starting point let s agree upon some basic concepts: Business continuity is the discipline of assuring that a business has a plan to resume operations in the event of loss of resources (people, facilities, technology, machinery, transportation, critical records or third-party suppliers) resulting in an unacceptable slowdown or loss of business operation. Disaster recovery is the discipline of recovering IT assets and services lost to the business. Crisis management is the process of executing a structured plan to manage the response to an event that affects business continuity or requires a recovery process. Risk management is the discipline of ascertaining and mitigating risks. In most cases this includes a wider definition of risk mitigation than that associated with a business disruption due to a loss of resources. Audit and compliance is the discipline of validating that specific processes are being followed and requirements met. Best Practices

2 One way of looking at the relationship of these groups within an organization is depicted in the following graphic: Business Continuity Disaster Recovery Crisis Management Risk Management Audit and Compliance As illustrated above, disaster recovery and crisis management are disciplines within business continuity management. Risk management overlaps the responsibility of continuity management, and audit and compliance has an overlapping responsibility across all risks areas within the company. An Approach The primary goal of a business continuity program is to coordinate the efforts of your business continuity group, your information technology organization, your audit and compliance and risk management functions, and the business units or departments responsible for developing or executing individual business-continuity, disaster-recovery or crisis-management plans. An architect or a designer starts a project with a vision of what the end-state will be. In business, we follow a process or framework, focusing more on the steps than on the end game. One suggestion would be to take the best of both of these approaches. Whether you re at the beginning of your program, or well into the program and looking for places to improve, following a structured process and having a specific end-state as a goal will significantly improve the outcome. Each of the different groups in your company, like the members of a team, should work together, having both individual assignments and a team goal. The audit and compliance and risk-management functions help identify gaps and direction; the business continuity team creates and coordinates the overall plan; the business units execute their individual recovery solutions; and the IT department oversees the technology. The role of the business continuity group What should a business continuity group be doing to fulfill its role in the program? It should: Establish an overall plan with both long- and short-term goals. This program plan should detail the steps that will be taken to build or expand the program. This should encompass both short-and long-term goals (see page 4). It should also include the required human resources, an estimate of the time commitment needed from those resources, and any budgetary impact. The program plan will be a key component of the justification or business case that may need to be developed to ensure executive support. page 2

3 The role of the business continuity group Establish an overall plan with both long- and short-term goals. Establish communication plans. Define recovery scenarios and severity levels to establish response protocols. Define the measurement and control points of the program. Be consultative to the business. Establish a framework for business units to use in building their own continuity plans. The business continuity group should not take on the writing of continuity or recovery plans for business units, departments or facilities. Instead, they should provide the structure and the framework for such plans, and supporting documentation. Individual plans won t be exactly the same as one another, but there should be similarities in context and framework from one plan to another. The business continuity group should set guidelines for the content and an appropriate level of response based on which resource is lost and the severity of the loss (see Define recovery scenarios and severity levels on page 4). Lastly, it s important for the group to establish that there is continuity in plan development, communication protocols, and test exercise objectives. Establish communication plans. The business continuity group will also draw up and maintain communication plans in line with the organization s crisis management plans (this may require an interface with corporate communications and legal). Some events will have an obvious prescriptive response, while others will rely on specified processes to determine the right responses and assure their timely execution. The business continuity team needs to ensure that the communication plan covers the processes for declaring a disaster, communicating what response plan has been put in motion, providing ongoing communications, and coordinating communication activities. The crisis management plan developed by the crisis management team coordinates the activities between senior and local management and other employees. It also establishes the activities for event lifecycle management (declaration, assessment, response), recovery team coordination and activity prioritization. The plan should have two specific parts: a strategic document describing the interaction between groups, and a tactical set of instructions much like a project plan. Define recovery scenarios and severity levels to establish response protocols. Business continuity planning means being able to call on an alternative resource if your primary resource becomes unavailable. Your plan should cover seven types of resource people, facilities, technology, machinery, transportation, critical records and third-party suppliers taking into consideration the severity of the loss and the expected length of the disruption. As an example, in planning for a flu outbreak you need an alternative resource plan for a people resource shortage. You have to define your critical people resources, determine how long you can operate without their specific service to your company, and develop a plan to cross-train others to do the job of those missing. In doing so you ve defined the parameters of the disruption, who and how many are out, and how long the disruption will last. In other words, you ve identified and delineated the disruption possibility and determined your recovery plan based upon the severity. Defining disruption severities allows you to set expectations of what you will and won t do when a disruption occurs. It helps determine when a disruption is really a disaster and, by nature of the definition, outlines an appropriate action. page 3

4 Define the measurement and control points of the program. Once your business continuity program is underway, it s important to articulate the progress that it s making. While common indicators include the number of mechanical outcomes (completed business impact assessments (BIAs), completed plans, etc.), other measurements could be the amount of risk mitigated, the preparedness of staff at a location, the success of the last exercise, or a self-evaluation by the senior manager in charge of the facility. While these types of measurements are less binary, and certainly more subjective, than the mechanical outcomes, they really help define the risk of not being able to recover from a disruption due to a lack of understanding or lack of preparedness by the relevant people. Be consultative to the business. Only by communicating with and helping the business-continuity user community within your organization (ie, those affected by the program), can you build their awareness and adoption of the program and evolve their maturity within the program. From the six points above we can see that the business continuity group generally has three main responsibilities when it comes to developing or refining the business continuity program: 1) Defining the framework and governance of the program. 2) Validating and measuring the results of the program. Building and maintaining a business continuity program is not a sprint, it s a journey. It requires a change in corporate culture. 3) Being the champions of the program. Four principles of successful business continuity programs As the business continuity group works to carry out these responsibilities, here are some tips for doing so successfully. Establish short- and long-term goals Building and maintaining a business continuity program is not a sprint, it s a journey. It requires a change in corporate culture. Establish your goals on both a short- and longterm scale (six-monthly or one-year increments work in most organizations). Make sure the goals are measurable, attainable, and easily communicated. If you re implementing a new program, good short-term goals include developing the charter and the framework of the program, while good long-term goals might be implementing communication and awareness programs. In an existing business continuity program, a good place to start is identifying the maturity of the program and comparing it to the risk tolerance of the organization. In general, this type of assessment pinpoints gaps that identify measurable changes to the program. Make sure it works There are many publications, instructions, processes and methodologies for implementing a business continuity program. Many of them could have you paying a lot of attention to the activities in the program, yet not producing a result that changes the continuity posture of your organization. Why? One business continuity manager from a large multinational organization spent more than a year working on the company s risk analysis. He first identified an impressive list of risks and potential threats. Next he investigated the historical occurrences of each of the threats, driving towards the root cause of several of the occurrences, and then assigning a probability of occurrence to each threat based on the likelihood of the company experiencing the same type of event again. At the end of the year, a pretty significant document was created. It was rich in facts and details; but it could not draw a specific conclusion or support any of the program recommendations. page 4

5 The problem is analysis paralysis. Gaining a better understanding of events is certainly important; indeed it s best practice. But no matter how much analysis you do, there s really no way to predict most disasters. So you need to match the analytical process with at least as much attention to the results you want to achieve and the actions you must take to achieve them. Here s a simple analogy. If you rely on your car for transportation, a flat tire is a threat to your transportation resource. Analyzing the incidence of flat tires might give you insight into the conditions most likely to cause a flat, but can never actually predict the next one. That s why the most important thing you can do is keep up with the normal maintenance schedule and regularly check to see if the spare is road-worthy. The spare tire mitigates the risk of losing your transportation resource, even though the loss event is not predictable. Methodologies, frameworks and standards all provide a set of guidelines to best practice in building your business continuity program; but a common mistake is focusing on the process and never looking at the results. So make time to take a step back and assess how integral to your company your business continuity program is. If it s not an integral part of the organization s culture and processes it s unlikely to give you the results you expect. Automate if you can Having a tool to automate a repetitive process can save time and money, providing the acquisition and implementation cost of the tool doesn t outweigh the benefit it provides. Many tools are available in the industry but not all add value. Some automate a process that is already automated; others take a methodology and automate that methodology, requiring you to adopt their way of doing things. Tools don t need to be complex in order to be useful. They just need to be able to economically assist you in getting a job done in the way that you want to do it. Tools don t need to be complex in order to be useful. They just need to be able to economically assist you in getting a job done in the way that you want to do it. The question, when selecting a tool, is: what are you expecting it to do? Evaluate what you want the tool to do and what alternative methods there are for achieving those ends, before assessing the features and functions of the tool, the level of customization you require (and how easy it is to customize), and what benefits the tool brings. Don t forget to consider the requirements of crisis management and disaster recovery planning; if a tool doesn t help with these elements of business continuity it s leaving out half the story. An important consideration for any tool set is how well it lets you identify the control and audit points in your program, and understand the level to which each location, department or person (as relevant) has executed that control. For example, say there s a requirement to review the business impact of a potential outage on a biannual basis. The departments that have completed that task are compliant, and those that have not are non-compliant. If this requirement is dictated by a standard framework that your organization is bound by, the exposure that exists because of non-compliance is a measurable risk that is important to understand. If you have many locations or departments covered by this requirement (maybe nationally or even globally), collecting this datum on compliance can be a daunting task unless it s a function of an automated control point in your business continuity management tool. The final question to ask is whether or not the tool lets you easily link to other functions of the business such as risk management, audit and compliance. Without such linkages, it s difficult to truly understand the business impact of business continuity activities over time. page 5

6 Don t confuse installation and implementation Business continuity tools can be complex, especially for larger organizations. Having a tool installed entails setting up the computing platform and configuring the software for access. It doesn t get you close to having a useful and productive tool for your program; for that you need an implementation plan. Success stems from understanding what you need to automate and what compromises you re willing to make with the tool that you select, as well as a realistic understanding of the benefits it can bring to your program. An implementation plan for a tool requires you to understand what you want automated, what you re expecting as a result, and how to work with the tool vendor to roll out these requirements after installation. The implementation process includes configuration, customization, and training for you and the end-user community on the tool s functionality and features. It may also cover requirements for integration with other tools, such as those for risk management or audit and compliance. Some organizations start by buying a tool and building their program around it. Others build their program and then buy a tool to support it. Both approaches have the same likelihood of success or failure. Success stems from understanding what you need to automate and what compromises you re willing to make with the tool that you select, as well as a realistic understanding of the benefits it can bring to your program. In your evaluation of any tool, ask to talk to the customers who are having difficulties implementing the tool, not just the reference customers. Conclusion While many organizations have a culture of separating the responsibilities for functions such as disaster recovery, crisis management, risk management, audit and compliance, and business continuity, there are working management structures, processes and tools that can help you have a coordinated approach to these related functions. In this way you can change the business continuity and recovery posture of your organization for the better. Written by John Linse, Global Competency Data Protection Service for EMC. John is a regular speaker at disaster recovery events, seminars and conferences, including recent presentations at EMC World, HIMMS, and local chapters of ACP. John has published a white paper, Decision in Disaster Recovery and is authoring another on data protection in a cloud architecture. page 6

7 About RSA RSA is the premier provider of security, risk and compliance solutions, helping the world s leading organizations succeed by solving their most complex and sensitive security challenges. These challenges include managing organizational risk, safeguarding mobile access and collaboration, proving compliance, and securing virtual and cloud environments. Combining business-critical controls in identity assurance, data loss prevention, encryption and tokenization, fraud protection and SIEM with industry leading egrc capabilities and consulting services, RSA brings trust and visibility to millions of user identities, the transactions that they perform and the data that is generated. EMC 2, EMC, RSA and the RSA logo are registered trademarks or trademarks of EMC Corporation in the United States and other countries. All other trademarks used herein are the property of their respective owners EMC Corporation. All rights reserved. Published in the USA. h9013-bccmdr-wp-0811