Disaster Recovery Business Continuity

Business continuity planning (BCP) is the creation and validation of a practiced logistical plan for how an organization will recover and restore partially or completely interrupted critical (urgent) functions within a predetermined time after a disaster or extended disruption. The logistical plan is called a business continuity plan.

In plain language, BCP is working out how to stay in business in the event of disaster. Incidents include local incidents like building fires, regional incidents like earthquakes, or national incidents like pandemic illnesses.

BCP may be a part of an organizational learning effort that helps reduce operational risk associated with lax information management controls. This process may be integrated with improving information security and corporate reputation risk management practices.

In December 2006, the British Standards Institution (BSI) released a new independent standard for BCP — BS 25999-1. Prior to the introduction of BS 25999, BCP professionals relied on BSI information security standard BS 7799, which only peripherally addressed BCP to improve an organization's information security compliance. BS 25999's applicability extends to organizations of all types, sizes, and missions whether governmental or private, profit or non-profit, large or small, or industry sector.

In 2007, the BSI published the second part, BS 25999-2 "Specification for Business Continuity Management", that specifies requirements for implementing, operating and improving a documented Business Continuity Management System (BCMS).

In 2004, the United Kingdom enacted the Civil Contingencies Act 2004, a statute that instructs all emergency services and local authorities to actively prepare and plan for emergencies. Local authorities also have the legal obligation under this act to actively lead promotion of business continuity practices amongst its geographical area.

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 alongside crisis management and disaster recovery planning and is a part of an organization's overall risk management.

The development of a BCP manual can have five main phases:

• Analysis
• Solution design
• Implementation
• Testing and organization acceptance
• Maintenance.

The above list is not exhaustive. There are a number of other considerations that could be included in your own plan / manual: - Risk Identification Matrix - Roles and Responsibilities (ensuring names are left out but titles are included, e.g. HR Manager) - Identification of top risks and mitigating strategies. - Considerations for resource reallocation e.g. skills matrix for larger organizations.

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.

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:

• Disease
• Earthquake
• Fire
• Flood
• Cyber attack
• Sabotage
• Hurricane
• Utility outage
• Terrorism

All threats in the examples above share a common impact: the potential of damage to organizational infrastructure - except one (disease). The impact of diseases can be regarded as purely human, and may be alleviated with technical and business solutions. However, if the humans behind these recovery plans are also affected by the disease, then the process can fall down. During the 2002-2003 SARS outbreak, some organizations grouped staff into separate teams, and rotated the teams between the primary and secondary work sites, with a rotation 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 non-salinated and contamination-free water (e.g., 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. Organizations sometimes underestimate the space necessary to make a move from one venue to another. It is imperative that organizations consider this in the planning phase so they do not have a problem when making the move.

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. A good asset management program can be of great assistance here and allow for quick identification of available and re-allocateable resources. For an office-based, IT intensive business, the plan requirements may cover the following elements which may be classed as ICE (In Case of Emergency) Data:

• 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.
• 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, loss of skill staff management, or restoration of embedded technology in process plant. This BCP phase overlaps with Disaster recovery planning methodology. The solution phase determines:

• the crisis management command structure
• the location of a secondary work site (where necessary)
• telecommunication architecture between primary and secondary work sites
• data replication methodology between primary and secondary work sites
• the application and software required at the secondary work site, and
• the type of physical data requirements at the secondary work site.