| Business Continuity Planning |
Article Index for Business |
Website Links For Business |
Information AboutBusiness Continuity Planning |
| CATEGORIES ABOUT BUSINESS CONTINUITY PLANNING | |
| anticipatory thinking | |
| business continuity and disaster recovery | |
| collaboration | |
|
Business Continuity Planning ('''BCP''') is a and "BS 7799 Information Security" respectively. A completed BCP cycle results in a formal Printed Manual available for reference before, during, and after disruptions have occurred. For the purposes of this article, the term ''disaster'' will be used to represent Natural Disaster , Man-made Disaster , and disruptions. Business Continuity Planning is not a new concept; plans for disasters, like Noah's Ark , are evidenced from the beginning of human History . In the years prior to January 1 , 2000 , governments anticipated computer failures, called the Y2k problem, in important social infrastructure like Power , Telecommunication , Health and Financial industries. Regulatory agencies subsequently required those industries to formalize BCP manuals to protect the public, those new regulations often based on the formalized standards defined under ISO/IEC 17799 or BS 7799. Regulatory and business focus on BCP arguably waned somewhat due to the problem-free Y2K rollover. This lack of interest unequivocally ended September 11th 2001 , when simultaneous terrorist attacks devastated downtown New York City and changed the 'worst case scenario' Paradigm for business continuity planning {Link without Title} . INTRODUCTION BCP methodology is attacks with well-developed and tested BCP manuals were back in business within days {Link without Title} . A BCP manual for a small organization may be simply a printed manual stored safely away from the primary work location, containing the names, addresses, and phone numbers for crisis management staff, general staff members, clients, and vendors along with the location of the offsite Data Backup Storage Media , copies of insurance contracts, and other critical materials necessary for organizational survival. At its most complex, a BCP manual may outline a Secondary work site, technical requirements and readiness, Regulatory reporting requirements, work recovery measures, the means to reestablish physical records, the means to establish a new supply chain, or the means to establish new production centers. Firms should ensure that their BCP manual is realistic and easy to use during a crisis. As such, BCP sits along side Crisis Management and Disaster Recovery Planning and is a part of an organization's overall Risk Management . The development of a BCP manual has five main phases: Analysis , Solution design, Implementation , Testing and Organization Acceptance , and Maintenance . Much of the BCP material on the internet is sponsored by consultancies who offer fee-based services for BCP solution development, however basic tutorials are freely available on the internet for properly motivated organizations {Link without Title} . ANALYSIS The Analysis phase in the development of a BCP manual consists of an impact analysis, threat analysis, and impact scenarios with the resulting BCP plan requirement documentation. Impact analysis An impact analysis results in the Differentiation between Critical and non-critical organization functions. A function may be considered critical if the implications for Stakeholders of damage to the organization resulting are regarded as unacceptable. Perceptions of the acceptability of disruption may be modified by the cost of establishing and maintaining appropriate Business or Technical Recovery solutions. A function may also be considered critical if dictated by Law . Next, the impact analysis results in the recovery requirements for each critical function. Recovery requirements consist of the following information:
Threat analysis suggested as a causative agent for the SARS outbreak in 2002]] After defining recovery requirements, documenting potential threats is recommended to detail a specific disaster’s unique recovery steps. Some common threats include the following:
All threats in the examples above share a common impact - the potential of damage to organizational infrastructure - except one (disease). The impact of diseases is initially purely human, and may be alleviated with technical and business solutions. During the also has a unique characteristic. If an office environment is flooded with non-salinated and contamination-free water (e.g.m, in the event of a pipe burst), equipment can be thoroughly dried and may still be functional. Definition of impact scenarios After defining potential threats, documenting the impact scenarios that form the basis of the business recovery plan is recommended. In general, planning for the most wide-reaching disaster or disturbance is preferable to planning for a smaller scale problem, as almost all smaller scale problems are partial elements of larger disasters. A typical impact scenario like 'Building Loss' will most likely encompass all critical business functions, and the worst potential outcome from any potential threat. A business continuity plan may also document additional impact scenarios if an organization has more than one building. Other more specific impact scenarios - for example a scenario for the temporary or permanent loss of a specific floor in a building - may also be documented. Recovery requirement documentation After the completion of the analysis phase, the business and technical plan requirements are documented in order to commence the implementation phase. For an Office -based, IT intensive business, the plan requirements may cover the following elements:
Other business environments, such as production, distribution, warehousing etc will need to cover these elements, but are likely to have additional issues to manage following a disruptive event. SOLUTION DESIGN The goal of the solution design phase is to identify the most cost effective Disaster Recovery solution that meets two main requirements from the impact analysis stage. For IT applications, this is commonly expressed as: # The minimum application and application data requirements # The time frame in which the minimum application and application data must be available Disaster recovery plans may also be required outside the IT applications domain, for example in preservation of information in hard copy format, or restoration of embedded technology in process plant. This BCP phase overlaps with Disaster Recovery Planning methodology. The solution phase determines:
IMPLEMENTATION The implementation phase, quite simply, is the execution of the design elements identified in the solution design phase. Work package testing may take place during the implementation of the solution, however; work package testing does not take the place of organizational testing. TESTING AND ORGANIZATIONAL ACCEPTANCE The purpose of testing is to achieve organizational acceptance that the business continuity solution satisfies the organization's recovery requirements. Plans may fail to meet expectations due to insufficient or inaccurate recovery requirements, solution design flaws, or solution implementation errors. Testing may include:
At minimum, testing is generally conducted on a biannual or Annual schedule. Problems identified in the initial testing phase may be rolled up into the maintenance phase and retested during the next test cycle. MAINTENANCE Maintenance of a BCP manual is broken down into three periodic activities. The first activity is the confirmation of information in the manual. The second activity is the testing and verification of technical solutions established for recovery operations. The third activity is the testing and verification of documented organization recovery procedures. A biannual or annual maintenance cycle is typical. Information update and testing All organizations change over time, therefore a BCP manual must change to stay relevant to the organization. Once data accuracy is verified, normally a call tree test is conducted to evaluate the notification plan's efficiency as well as the accuracy of the contact data. Some types of changes that should be identified and updated in the manual include:
Testing and verification of technical solutions As a part of ongoing maintenance, any specialized technical deployments must be checked for functionality. Some checks include:
Testing and verification of organization recovery procedures As work processes change over time, the previously documented organizational recovery procedures may no longer be suitable. Some checks include:
Treatment of test failures As suggested by the diagram included in this article, there is a direct relationship between the test and maintenance phases and the impact phase. When establishing a BCP manual and recovery infrastructure from scratch, issues found during the testing phase often must be reintroduced to the analysis phase. SEE ALSO
REFERENCES
FURTHER READING
EXTERNAL LINKS
|
|
|