Talk:Business continuity planning

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Cscr-former.svg Business continuity planning is a former featured article candidate. Please view the links under Article milestones below to see why the nomination failed. For older candidates, please check the archive.
WikiProject Business (Rated B-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Business, a collaborative effort to improve the coverage of business articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
B-Class article B  This article has been rated as B-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
 

Withdrawn standard referenced[edit]

BSI standard 25777:2008 is replaced by ISO 27031:2011 so should reference to that withdrawn standard be removed from the list? I think it causes unnecessary checking for information seekers. Sohannin (talk) 20:43, 6 March 2012 (UTC)

Most recent FAC[edit]

I raised the following article once before and I believe the current article has addressed all the objection points raised during the first round:

  1. No references - References Added.
  2. BCP is not "a methodology to create a manual" - Wording corrected.
  3. BCP has a lot of overlaps with the risk management process, but this article doesn't even consider that link. - Referenced in the first paragraph, since this is not an article about Risk Management, risk management doesn't need to be explained.
  1. no examples of BCP in real life. - Added
  2. No examples of failure of organisations which did not do it and had problems because of it. - Added
  3. No examples of failures of organisations which did do it. - Added
  4. no comments on risk acceptance and the impossibility of completely protecting against all disasters.
  5. extremely focused on small business / office scenario, what about BCP for large factories? Does the BCP methodology not cover that area? - Disagree with this point. The BCP process is applicable to any type of activity, as long as the organization classifies a non-office function like distribution as "critical". I think this is clear.
  6. what about other ways of doing it? - Sorry, there is not other ways of going through a BCP process. If you bypass the process (or a phase in the process), your plan will stink....
  7. please add copyright notice to your diagram. - Done
  8. please add comparison to methodologies used in Japan and Taiwan where a disaster like 9/11 is considered relatively small and massive earthquakes are expected to be handled effectively. - BCP process is the same regardless of the location or the threat!
  9. please consider linking citations - Added.

Let’s see what the second round turns up. Please review for featured article status Revmachine21 12:42, 30 Apr 2005 (UTC)

First FAC[edit]

It looks like a nice article so far (I'm no expert in the field, so I can't judge any content). As a laypeson, however, I'm missing context. Where does BCP come from? You must establish that it's not original research rightaway by mentioning who originated this methodology, or in what field it started. Any books to add to the references? JRM 14:43, 2004 Dec 12 (UTC)

Thanks again JRM, good input. My professional background is in BCP (i.e. BCP Manager) and this content originated from my head; I was trained on the job in the finance industry. I will need to research the historical precedents to the 'science'. BCP methodology is advocated by governments for organizations of all sizes so it is not proprietary. This can be a highly complex field and I am struggling to keep the context general enough for small industry, non-profit, educational organizations etc. As way of reference, my last firm's BCP manual was 400+ pages long. From your comments sounds like I've made it too generic and need to add color. Revmachine21 15:18, 12 Dec 2004 (UTC)
Genericity is not bad; Wikipedia is a secondary source. However, anything we say should also be verifiable—i.e, we must mention what we're generalizing over. ("Cat flinging is a hobby practiced by sadists. It was first mentioned in a 1974 article by Isaac Isaacson published in "Unethical Biology" [...] According to Fred Foobar of the Ministry of Excellence, one should always keep the cat to be flung by the tail, but multiple sources, including the Association of Feline Deviants, claim any body part will do.") Etcetera, etcetera, followed by references to the article, Foobar's statement, and multiple references including one for the AFD.
Paraphrasing and summarizing is allowed (necessary, even), but we should always strive to check our facts and cite our sources. An article that's "made up" by someone from working knowledge is better than none at all (in fact, the vast majority of articles in Wikipedia starts like that and many never get any further), but an article that can mention where it came from is even better. However, that's not of immediate importance. You can focus on getting everything of importance in before trying to tie it all to sources. See also Wikipedia:How to write a great article, which goes in great detail on how to best approach this sometimes daunting task. JRM 18:57, 2004 Dec 12 (UTC)

Comments[edit]

I have comments on this topic. The overall concept of Business Continuity and Disaster Recovery Planning are under review and development by the ISO to create a family of standards similar to the ISO 9000 family for Quality Management. This new family will be covered in the ISO 27000 family and several of the existing standards as mentioned below will fold into this new family of standards including ISO 17799, ISO 24762, ISO 27001, BS 25999-1. These are discussed in ISO/TC 223 (IWA 5:2006). [1]

The overall principle here is that Disaster Recovery is primarily designed for technology and as such is designated as specific to technology only within the proposed standards. Business Continuity Management is the holistic view for managing risk to continued operation of business. Business Continuity Planning (Plans) are the governing documentation that will include all the aspects of risk mitigation; including security, technology, preparation and recovery for the various scenarios up to and including a pandemic.

Therefore the information consolidation should take place under the heading of “Business Continuity Management” not Business Continuity Plan. This will enhance the value of information offered. 19:54, 30 May 2007 (UTC)19:54, 30 May 2007 (UTC)WoodstockDan 19:54, 30 May 2007 (UTC)

I have some comments on the article. However, overall it is a good article, and my comments should be read in that context. Indeed, I hope the fact that they will be obscure points, to most 'lay persons', underlines that.

(1) I feel that your article is too focussed on the IT aspects of business continuity. The methodology you described comes from the IT business continuity standards. BS7799 is still valid as an IT standard, but the British Standards Institute is developing a new standard based on PAS56, which is what most UK business continuity practitioners work to (see www.thebci.org). The London bombings of 7/7 exposed that too many organisations’ BCPs did not give enough thought to the human aspects of emergencies.

Two ideas here, (1) add what you think is appropriate about PAS56, and/or (2) add a section to describe the such local standards to de-Westernize the article as you see fit. If I don't like it, I will edit. Revmachine21 13:48, 16 August 2005 (UTC)
BS7799, or ISO17799 as it's known internationally, is indeed chiefly an IT standard, with some more general disaster management procedure standards. It's also official, and recognised by British Standards (not called the BSI any more) and the International Organization for Standardization. Whereas PAS56 is a "standard" created by a for-profit organisation calling themselves the Business Continuity Institute (£60 / $111 to see a standard? Real standards are available for free), with under 2000 members worldwide. Any mention of this 'PAS56' will be veering close to advertising. (Try and find anything on PAS01 - PAS55!). Proto t c 14:16, 16 August 2005 (UTC)
As I stated, PAS56 is the basis for a new business continuity standard, that will shortly be published by British Standards. The Publically Available Specification Publically Available Specification IS published by British Standards, and they hold the copyright. You may not be able to find 1 to 55 - they have probably been developed to full standards! It is also referred to and recommended by the UK government's statutory guidance to public sector organisations: see Emergency Preparedness (warning! large pdf file) section 6.43 Sneakysnaga t c 20:57, 16 August 2005

I would like to comment on your comments, if I may. The new British Standard for Business Continuity, which is to be BS 25999, will replace PAS 56, but I don't belive it is based on PAS 56. I understand that the expert committee involved with its development are building it from the "ground up". BS 7799, as it was called, was in two parts. A Specification and A Guidance. The Guidance part (part 1) was adopted by ISO and called ISO/IEC 17799. Part 2 of the standard is the specification, which means companies can be audit to the standard, or if the wish, to certify to the standard. It is a management system for Information Security and not just IT Security. Yes, it was developed by the IT ISO technical committee, but it is an organization wide standard. In October 2005 this part of the standard was adopted by ISO and is now ISO/IEC 27001:2005. ISO/IEC 17799:2005 will become ISO/IEC 27002 in 2007, but this is expected to be a name change only. BSI Still exists as a company, but has four divisions, one of which is Britsh Standards (I have BSI on my business card). Can I propose that Business Continuity really is about the planning (BCP) of how an organization cn return to normal business operation in the event of a disaster, Service Continuity is about recovering the IT service delivery and Disaster Recovery is about recovering the organizations information in the event of a disaster? The circumstances of when information is lost may be different to the circumstances of when there is an organization wide disaster. Business Continuity is led by the business. Disaster Recovery and Service Continuity are a subset of Business Continuity. --Rob 12:36, 5 April 2006 (UTC)

(2) Business Continuity Management emerged from Disaster Recovery, as organisations realised that a focus on IT recovery from disruption might be irrelevant if the wider business could not operate. Business Continuity today focuses as much on business processes, as the IT underpinnings of those processes. It is also tightly coupled with Crisis Management, which aims to ensure the reputation of the organisation survives an incident intact. This topic should be mentioned and linked to.

Please do so. Revmachine21 13:48, 16 August 2005 (UTC)
P.S. Went back and checked the article, Crisis Management is already referenced. Revmachine21

(3) There is much debate about DR and BCM as labels for activities, which is in part because of the historical roots of the discipline. This reflects that there is a continuum of related activities that may take place under this heading, with a variety of methods. Accordingly, setting out a single method as correct is probably not appropriate for this article.

Don't understand what you mean here. Personally would avoid an archane treatise about terminology. This is supposed to be an encyclopedia article for the general public, not a PhD dissertation going into the quantative differences between word X and Y. Revmachine21 13:48, 16 August 2005 (UTC)
Correct, there is no single 'correct' method of business continuity planning. They all share the same underlying principles, however. Proto t c 14:16, 16 August 2005 (UTC)

(4) You state that “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.” Your citation is to an opinion piece, which itself has no evidence that this paradigm shift has taken place, and is in fact a call for it to take place. By contrast there is much evidence to suggest that many organisations still do not have business continuity plans at all.

Sorry, totally disagree. Regulators, particularly financial regulators, have raised the mark dramatically, added miles/kilometers to minimum safe distances. Companies raised their budgets. Drills became more serious. This is personal experience earned by force marching staff down 37 flights of stairs to make sure they knew how to get out of my high-rise building and being subjected to much more audit scrutinity of my BCP plans. Oh, BTW, when we got to the bottom floor we found the emergency exits were locked from the outside. If that had been for real, we woulda been spam in a can. Revmachine21 13:48, 16 August 2005 (UTC)
Indeed. ISO 17799 didn't exist in its current form until after September 11. A far greater emphasis on disaster planning, business contoinuity, crisis management, whatever you want to call it has definitely been visible since 2001. Proto t c 14:16, 16 August 2005 (UTC)

(5) My comments are based on the UK experience, and my reading of your article is that it is mostly relevant to the ‘West’. I would suggest that for a global resource such as the Wikipedia, a context statement is relevant. I personally have no idea about the global spread of business continuity but imagine it is less well advanced in the other parts of the world.

I would argue that the BCP discipline is driven by heavily regulated industries such as finance, pharmaceutical, energy, health, etc. In all those fields, the 'West' unfortunately leads the rest of the world, other countries tend to follow, all-be-it with their own adaptions. If you can come up with some relevant information to add a non-Western spin, please do so. Revmachine21 13:48, 16 August 2005 (UTC)
Excellent comments it seems. You clearly have a detailed knowledge of the subject and it is exactly someone like you that needs to fix the things you see. No one, even a very knowledgeable person, such as Revmachine21 who I believe wrote nearly the entire article can write without any bias, and you may have uncovered it, or you may be off base on some of your comments--I don't know enough about the subject to decide. But you and Rev can discuss it and fix the issues. Please find the relevant sources and cite them so that the article can be as verifiably correct as possible. Consider signing up for a username and helping to improve the article. Thanks - Taxman Talk 12:22, August 16, 2005 (UTC)
Thank you Taxman. I have now signed up for a username. I will endeavour to help out as much as possible. Time permitting! Sneakysnaga t c 20:57, 16 August 2005

(6) Regarding the suggestion to merge this article with Disaster Recovery

The concept of Disaster Recovery only embraces one aspect of Business Continuity and the planning that an organization must undertake to ensure reliable service delivery. Perhaps "Disaster Recovery" and "Business Impact Analysis" would more appropriately exist separately from, but still contain links to, "Business Continuity Planning." Networktester  t c 12:09, 25 February 2006
Disaster recovery is already in existence, click link. Also agree that it should remain separate. The Business Impact Analysis would have to be a new article, probably a nice addition too. Have at it & have fun! Revmachine21 00:24, 26 February 2006 (UTC)

There is over reliance on BS7799. We will have to appreciate that BS7799 is a information security standard and it does not clearly spell out BCP practices. BCP is not about IT only! what happened in Kathrina storm/9-11/Mumbai floods is not about IT alone. It's time we cleaned up this article. Let's do justice to field of BCP and put content accordinly.

Fabulous idea darling. Please proceed. Revmachine21 08:46, 13 October 2006 (UTC)

Article Introduction[edit]

Can I make a few comments on the article introduction?

This article is redirected from Business Continuity Management and the terms are largely interchangeable. I actually think management is a better reflection of what actually happens, the word planning assumes never actually doing. Would it be appropriate to mention the fact that the two terms are commonly interchanged.

It is not necessarily a peer mentored process, why is this one in

It does not produce a plan but a capability. This seems to reflect that the whole point of BCP is to create a plan

The aim should be to recover some or all of an organisations processes but critically, and this is not mentioned, to a pre agreed level. It is not about business as usual but getting to an agreed level within a target time

It does seem to be UK centric with no mention in the introduction of other standards such as the North American NFPA 1600, Australian HB292/3 and ISO/PAS 22399. Also not sure what the Civil Contingencies Act in the UK has much to do with the subject.

Prior to the introduction of BS25999 BCM professionals did not have to rely on BS7799 as stated in the article. BS7799 and its subsequent revisions is an Information Security Management standard that includes a section on business continuity. One of the three pillars of information security management is availability. This is obviously relevant but there were other documents that BCM professionals could use including PAS56 (a fore runner of BS25999), earlier versions of NFPA1600, earlier versions of HB292/3 and the various generally accepted practice documents produced by the BCI and DRI

Would it be appropriate and accepted to make some changes based on these observations? —Preceding unsigned comment added by Samsungjohnny (talkcontribs) 15:13, 13 January 2008 (UTC)

The topic of the page is Business Continuity Planning. It is thus preferable not to over-develop tangental aspects. Equally, not use additional material to place links to your own site. —Preceding unsigned comment added by 66.84.37.52 (talk) 15:52, 13 January 2008 (UTC)

I am suggesting changing the content, not to develop tangential topics or link to my own content. Please read my suggestions rather than jumping to conclusions. Samsungjohnny (talk) 16:08, 13 January 2008 (UTC)

Change of content for an established page like this should be evolutionary and built upon long term consensus. Radical change, is not required. Previous edits illustrate my concern. 66.84.37.52 (talk) 19:57, 13 January 2008 (UTC)

OK, whatever. I will present my suggestions in another way then if a wholesale change is not the correct way of moving forward. The introduction to the article suffers from a UK focussed perspective and is a little misleading in some respects not accurately reflectng the current best practice in BCP, so here goes, my tuppence worth for user review

FIRST PARA Remove peer mentoring. BC Planning is not necessarily a peer mentored process

Change logistitical plan to capability. Capability is a mcuh more relevant subject because the plan is made up from a variety of processes, systems etc

Add after predetermined time, and to a pre defined level. A recovery does not necessarily have to be to a full level but will probably be at a reduced level

Remove extended disruption and replace with disruptive event. This leads the reader into thinking that the only things that cause business continuity to be used is a disaster or extended disruption but BCP seeks to mitigate a broad range of disruptions

Remove the logistical plan is called a business continuity plan. Business continuity planning produces a wide range of documented systems only one of which is the business continuity plan


SECOND PARA Change mission to activity and change longterm health to longterm viability

Broaden out the range of incidents described to include, IT problems, information security breaches and others

THIRD PARA Change the word lax to poor. Lax indicates a lack of activity but it is not just the lack of activity but also the wrong activity

FOURTH AND FIFTH PARA These seem to be very UK focussed and I am not sure what the UK Civil Contingencies Act has to do with the subject. Can I suggest replacing these two paragraphs entirely to refelect the fact that a number of professional institutes and standards bodies have standards and guidance documents, maybe listing some examples. The previous edit that has been stricken did include a suggestion to this but I wont be so prescriptive here.

Over to editors for view Samsungjohnny (talk) 21:16, 13 January 2008 (UTC)

Moving "How-To" Guidelines into Wikibooks[edit]

See peer review article updates before mass reversion of Master Business Continuity Planner (MBCP) work-in-process

-- 66.45.145.191 14:17, 26 October 2006 (UTC)
Note: This migation process required purging all external URLS
-- 66.45.145.191 14:31, 26 October 2006 (UTC)
Replaced non-"How To" sections with corrected peer review version.
geoWIZard-Passports 10:30, 10 December 2006 (UTC)

Introduction[edit]

BCP methodology is scalable for an organization of any size and complexity. Even though the methodology has roots in regulated industries, any type of organization may create a BCP manual, and arguably every organization should have one in order to ensure the organization's longevity. Evidence that firms do not invest enough time and resources into BCP preparations are evident in disaster survival statistics. Fires permanently close 44% of the business affected [2]. In the 1993 World Trade Center bombing, 150 businesses out of 350 affected failed to survive the event. Conversely, the firms affected by the Sept 11 attacks with well-developed and tested BCP manuals were back in business within days [3].

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 [4].

From reading this it seems that the whole point of BCP is to produce a manual. This is not the case at all. It is to produce an ongoing capability and changes with the organisation and its goals and resources.

It also defines the BIA process in rather prescriptive terms. A BIA can and should be suitable for the organisation not following the defined zones as described here

The description about BCP post Y2K and post the 9/11 attacks are extremely US focussed. The UK, which has experienced 30 odd years of Northern Irish terrorism has developed arguably the most mature BCP capabilities precisely because of it.

The various standards and accepted best practice guidelines from various public and private sector organisations seek to promote BCP so that organisations are not compelled to seek third party consultants

The main area of concern I have for this section though is the concentration on producing a BC Manual

Samsungjohnny (talk) 21:32, 13 January 2008 (UTC)

Analysis[edit]

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[edit]

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:

  • The time frame 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[edit]

The coronavirus 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 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 [11]. Damage from flooding 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.

I added some more to the article (such as random failure of mission critical systems), but I also think "Terrorism" should be removed. Loss of Confidentiality (or theft), Availability, or Integrity of critical information or material, or loss of mission critical functionality is the goal of any attacker - terrorist, hacker, or Other. I see no difference between a Terrorist and and Insider intend to do the same damage (sabotoge or other forms). I suggest simply the introduction of an internal or external threat entity.--74.107.74.39 (talk) 23:50, 26 March 2011 (UTC)

Definition of impact scenarios[edit]

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[edit]

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 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[edit]

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:

  1. The minimum application and application data requirements
  2. 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:

  • 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.

Implementation[edit]

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[edit]

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:

  • Crisis command team call-out testing
  • Technical swing test from primary to secondary work locations
  • Technical swing test from secondary to primary work locations
  • Application test
  • Business process test

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[edit]

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[edit]

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:

  • Staffing changes
  • Staffing persona
  • Changes to important clients and their contact details
  • Changes to important vendors/suppliers and their contact details
  • Departmental changes like new, closed or fundamentally changed departments.

Testing and verification of technical solutions[edit]

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[edit]

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 accurate for staff?
  • Do the documented work process recovery tasks and supporting disaster recovery infrastructure allow staff to recover within the predetermined recovery time objective?

Treatment of test failures[edit]

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.

-- 66.45.145.191 13:22, 26 October 2006 (UTC)

Managing collaborative groups[edit]

Please explain the addition of this descriptor to the introductory image? I certainly did not have 'managing collaborative groups' in mind when I created the image. When looking at the wikilink to the MCG outine, nothing particularly jumped out at me to indicate why MCG had any relevance to BCP or the planning process. Please explain your reasoning. Thanks in advance. P.S. Some of the recent changes are quite nice additions. Revmachine21 10:48, 10 December 2006 (UTC)

Repeat request for clarification... otherwise I'm deleting the text. Revmachine21 02:15, 24 March 2007 (UTC)

Merge Bs 25999[edit]

An article about the standard for BCP would seem to have a huge overlap with this article. Is there really sufficient distinguishable material for a separate article? -- Whpq 02:41, 19 January 2007 (UTC)

I don't agree. BS 25999 is a significant new development and will evolve into a large topic itself especially when it becomes and ISO standard. It should not be merged into this topic.Binarygal
I don't agree with the merger proposal. BCP stands independent of BS25999 and was in existence before the standard. Seems to me that the BS25999 article needs a rework and expansion in line with the other BSI standards. Revmachine21 02:14, 24 March 2007 (UTC)
I wikified the Bs 25999 page today, but do not have enough experience with the subject to expand the article. As said above, it needs a rework as well. I originally supported a merge based upon the shape of the Bs 25999 article, but I'm deferring to others on this one - they know more than I do about the appropriateness of the merge. *Vendetta* (whois talk edits) 23:13, 1 April 2007 (UTC)

Exercising care developing the first paragraph & first section[edit]

The Intro paragraph grew (in a good way from an information standpoint) and got clunky. Let's be more careful from a style perspective when editing! The Introduction section has been expanded with materials moved out of first paragraph. IMO, the Intro section needs more work. I will do what I can but request collaboration from those other Wikipedian's monitoring this page. Revmachine21 01:40, 24 March 2007 (UTC)

Slightly expanded view of BCP[edit]

BCP is more than recovery from disasters: fire, flood, earthquake and/or pandemics. BCP is a plan to handle all of the bumps thrown at a business: competitive price drops, worker strikes, increased minimum wage etc.... The data on this page is good, but it seems to be excessively focused on the DRP side of BCP (and the DRP page is lacking much of this material). Maybe this could be refocused in the future? Iam.the.Unkn0wn1 4:28, 18 July 2007 (UTC)

Comment on section regarding BCP Standards[edit]

I would suggest that the author of this fine article consider adding comments regarding NFPA 1600 to the standards discussion. As it stands now, readers will assume that the only BCP standard that exists is BS25999, which is used primarily in the UK. In the U.S., the predominant standard is NFPA 1600, and I believe it deserves equal attention.

--MJKuras 18:38, 13 December 2007 (UTC)MJKuras

StandardsDirect.org[edit]

I removed the link to a standards purchase site, standardsdirect.org. See Wikipedia talk:WikiProject Spam#StandardsDirect.org for more about this site. As I see it, Wikipedia is not a directory and we're not here to help people sell things. Most of these standardsdirect.org links have been added by single purpose accounts who likely have a conflict of interest. See:

If an established, high-volume editor wants to add it back to the article, by all means go ahead. Otherwise, it stays out pending resolution at the spam discussion link above. --A. B. (talkcontribs) 00:43, 23 October 2008 (UTC)

Maximize what?[edit]

The standard provides a best practice framework to minimize disruption and maximize recovery time Excuse me, could somebody explain me in a sentence, why a long recovery time is better than a short one? If I were a company, I would maximize recovery speed or minimize recovery time.--Kifo (talk) 10:24, 12 July 2013 (UTC)

I agree. Seems the entire phrase doesn't belong there. Removing it........ My name is Mercy11 (talk) 02:25, 13 July 2013 (UTC), and I approve this message.

Title and content as a whole[edit]

This article does not really discuss business continuity planning, but almost exclusively the subset of it that is disaster recovery, and indeed primarily only with reference to natural disasters, rather than collapsing and needing to be recovered.

The fundamental goal of business continuity planning is assurance of resilience so that business continues to operate in the face of incidents. This point is so fundamental I'm amazed it has been omitted by the authors of this article. 212.159.59.5 (talk) 10:51, 27 August 2014 (UTC)