Business continuity planning: Difference between revisions
Revmachine21 (talk | contribs) →Maintenance: Reordering of sentence structure |
Revmachine21 (talk | contribs) →Solution design: Expanded BCP solution design |
||
Line 44: | Line 44: | ||
# The minimum application and application data requirements |
# The minimum application and application data requirements |
||
# The timeframe in which the minimum application and application data must be available |
# The timeframe in which the minimum application and application data must be available |
||
This BCP phase overlaps with [[Disaster recovery|Disaster recovery planning]] methodology. |
This BCP phase overlaps with [[Disaster recovery|Disaster recovery planning]] methodology. The solution phase determines: |
||
* The location of a secondary work site |
|||
* Telecommunication architecture between primary and secondary work sites |
|||
* Data replication methodology between primary and secondary work sites |
|||
== Implementation == |
== Implementation == |
Revision as of 03:17, 14 December 2004
Business Continuity Planning (BCP) is a methodology to create a printed manual that an organization will use to resume partially or completely interrupted critical function(s) within a predetermined time after a disaster or disruption. For the purposes of this article, the term ‘disaster’ will be used to represent natural disasters, man-made disasters, and disruptions. BCP 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 Y2k, governments anticipated computer failures 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. Regulatory and business focus on BCP waned somewhat due to the problem-free Y2K rollover. This disinterest ended September 11th, when simultaneous terrorist attacks devastated downtown New York city and changed the 'worst case scenario' paradigm for business continuity planing.
BCP methodology is scalable for an organization of any size and complexity. Even though BCP methodolgy has roots in regulated industries, any type of organization may create a BCP manual. A BCP manual for a small organization may be a simple as a printed manual containing the names, addresses, and phone numbers for crisis management staff, general staff members, clients, and vendors along with the location of the data backup storage media. At its most complex, a BCP manual may outline the secondary work site, technical requirements and readiness, regulatory reporting requirements, work recovery measures and many other informational components. As such, BCP encompasses Emergency Management, Disaster recovery planning, Contingency planning, and Business resumption planning.
The development of a BCP manual has five main phases: analysis, solution design, implementation, testing and organization acceptance, and maintenance.
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 damage to the organization is sufficient to warrant the cost of establishing and maintaining a business or technical recovery solution. 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:
- The description of the critical function
- The timeframe in which the critical function must be resumed after the disaster
- The business requirements for recovery of the critical function, and/or
- The technical requirements for recovery of the critical function
Threat analysis
After defining recovery requirements, documenting potential threats is recommended to detail a specific disaster’s unique recovery steps. Some common threats include the following:
- Cyber attacks
- Disease
- Fire
- Flood
- Earthquake
- Power or telecommunication outage
- Terrorism
- Typhoon
All threats in the examples above share a common impact, potential of damage to organizational infrastructure, except one: disease. Diseases’s impact is purely human but can be ameloriated with technical and business solution. During the 2002-2003 SARS outbreak, some organizations selected staff for two teams, rotated the teams between the primary and secondary work sites, with a frequency equal to the incubation period of the disease. The organizations also banned face-to-face contact between opposing team members during business and non-business hours. With such a split, organizations increased their resiliency against the threat of government-ordered quarantine measures if one person in a team contracted or was exposed to the disease. Damage from flooding also has a unique characteristic. If an office environment is flooded with unsalinated and contamination-free water, 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 elements in a larger disaster. The ‘Loss of Building’ impact scenario 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 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. The plan requirements may cover the following elements:
- The numbers and types of desks, whether dedicated or shared, required outside of the primary business location in the secondary location
- The individuals involved in the recovery effort along with their contact and technical details
- The applications and application data required from the secondary location desks for critical business functions
- The manual workaround solutions
- The maximum outage allowed for the applications
- The peripheral requirements like printers, copier, fax machine, calculators, paper, pens etc.
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:
- The minimum application and application data requirements
- The timeframe in which the minimum application and application data must be available
This BCP phase overlaps with Disaster recovery planning methodology. The solution phase determines:
- The location of a secondary work site
- Telecommunication architecture between primary and secondary work sites
- Data replication methodology between primary and secondary work sites
Implementation
Under development
Testing and organizational acceptance
Under development
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 review and correction
All organizations change over time, therefore for a BCP manual to remain relevant over time, the manual must also be updated to reflect organizational changes. Some types of changes that should be identified and updated in the manual include:
- Staffing changes
- Staffing personal detail changes like address and telephone numbers
- Changes to important clients and their contact details
- Changes to important vendors/suppliers and their contact details
Testing and verification of technical solutions
As a part of ongoing maintenance, any specialized technical deployments must be checked for functionality. Some checks include:
- Virus definition distribution
- Application security and service patch distribution
- Hardware operability check
- Application operability check
- Data verification
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:
- Are all work processes for critical functions documented?
- Have the systems used in the execution of critical functions changed?
- Are the documented work checklists meaningful and accurated for staff?
Further reading
External links to BCP related articles
- United States General Accounting Office Y2k BCP Guide
- Department of Homeland Security Emergency Plan Guidelines
- NFPA 1600 Standard on Disaster/Emergency Management and Business Continuity Programs
- FEMA Standard Checklist Criteria For Business Recovery
- The Business Continuity Institute
- The Disaster Recovery Institute International
- Disaster Recovery Journal
- Business Continuity Online
- DIR Texas Department of Information Resource