The basic process for developing a business continuity plan is:

• Create a business continuity planning team: Members should be from operations management, the chief security officer, the IT department, legal staff, and human resources.
• Define leadership roles: Determine which executives and employees are critical to operating the business (and supporting customers) that need to have access to key systems and information at all time.
• Assume the worst and plan for needed extra capacity: Before an event occurs, businesses need to plan ahead for increased network bandwidth and secured remote access requirements.
• Define emergency voice and data communications solutions: There are many to choose from, but a SSL VPN is one of the leading solutions to provide flexible, remote access, which is essential to any business continuity plan.
• Define access points for operations, network and IT: Create a business continuity portal for employees and partners. If the company has an Intranet, this site becomes command central from which employees can access information - HR policies, emergency contacts and a "start here" feature should be included.
• Contract for a secondary back-up site: Should the primary site be unavailable, companies should have a real-time mirror of data and staff housed at a secure facility.
• Backup data: In the event that the secondary site is unavailable, organizations should plan for multiple layers of failover.
• Plan to utilize smartphones and tablets: With mobile devices and "wireless networks", IT departments can leverage these tools to ensure complete connectivity in times of emergencies.
• Pre-arrange Internet meeting capabilities: In the event of an office closure, employees still need to communicate internally or with external parties (i.e. suppliers, customers). Implement the technology before it is needed
• Review number of sites and VPN gateways: Conducting an annual audit to provide a complete picture of your network and the ability to address problem areas before a disaster strikes.
• Test and  test again: These 'fire drills' enable the business continuity team to see how the current system is working, especially when employees are accessing information from remote locations (i.e. from home, a relative's house, and hotel). Once complete, those in management, IT and human resources can modify their business continuity plan accordingly.
  

• Question that need to be answered are:
• Is our data safe in transit and at rest?
• What prevents hackers from gaining access to our data?
• Is our data properly handled, stored, and deleted?
• Who can access our data?
• What are the benchmark measurements?
• Is our data backup strategy compliant?
• Will our recovery be successful?

Business continuity planning is a continual process, and not something that is done once and filed away to be used in an emergency. In error many organisations treat the creation of a business continuity plan as a normal project, subsequently deploying the plan and handing over to an operational department for maintenance.

In most organizations, DR is the quintessential complex, unfamiliar task. Disasters happen so rarely that recovery operations are the opposite of routine. What's more the myriad, interconnected data, application and other resources that must be recovered after a disaster make recovery an exceptionally difficult and error-prone effort.

How to create a business continuity plan...

• Extending management technologies that automate the process of asset management, system configuration, and software distribution (This reduced the number of steps that required hands-on intervention and reduced IT staff time.)
• Constraining their environment to a finite number of standard processors, operating systems, database products - making it easier to maintain and update
• Consolidating servers over a long-term road map, reducing the number of server "footprints" that had to be maintained and updated
• Standardizing IT practices, especially management of settings and configurations
• Providing protected storage space within the organization's storage resources and establishing rules for backup of mission-critical data (This ensured adequate capacity for backup and recovery procedures and for restart of applications.)
  

ISO says that ISO/IEC 27035:2011 will help organizations respond to information security incidents, including the activation of appropriate controls for the prevention and reduction of, and recovery from, impacts, and, in so doing, learn and improve their overall approach.

Edward Humphreys, whose team developed the original version of the standard, ISO/IEC TR 18044:2004, commented: “Effective and timely handling of major incidents can make the difference between the survival or death of an organization. The new ISO/IEC 27035 standard provides tried and tested advice on the processes and methods that need to be deployed for ensuring effective management of information security incidents.

Incidents can vary from the minor, which may have an impact on an isolated business system to a major incident, which affects all business systems. Some incidents have the effect of disrupting an organization and the use of its business resources for 24-72 hours or more; some cause a serious loss and/or destruction of data and some can leave the organization with a serious crime on their hands. ISO/IEC 27035:2011 offers a solution.

ISO/IEC 27035:2011, which replaces technical report ISO/IEC TR 18044:2004, supports the general concepts specified in ISO/IEC 27001:2005.

The new standard is applicable to any organization, irrespective of size. It covers a range of information security incidents, whether deliberate or accidental, and whether caused by technical or physical means.

The Business Continuity Institute's Good Practice Guidelines defines MTPD as "The duration after which an organization's viability will be irreparably damaged if a product or service delivery cannot be resumed." This seems straightforward and unambiguous enough, but it's only when you look closely at the definition and try to think about how it might be applied in practice that you'll see that not only is it of very little use, but it is also different from what was originally intended.

If something does not work in practice then the theory is wrong. The idea that there is some point beyond which an organization's viability will be irreparably damaged if a product or service delivery cannot be resumed would be an extremely useful concept if such a thing existed. However, in practice, you will never really know if an organization's viability has been irreparably damaged until the organization fails, let along the point at which this happens.

Disaster Planning - Janco has found that 80% of all enterprises that do not have a disaster recovery / business continuity plan in place before a disaster occurs never reopen.  However, when disaster strikes, those who have prepared and made recovery plans survive with comparatively minimal loss and/or disruption of productivity.

Disasters can take several different forms. Some primarily impact individuals -- e.g., hard drive meltdowns -- while others have a larger, collective impact. Disasters can occur such as power outages, floods, fires, storms, equipment failure, sabotage, terrorism, or even epidemic illness. Each of these can at the very least cause short-term disruptions in normal business operation. But recovering from the impact of many of the aforementioned disasters can take much longer, especially if organizations have not made preparations in advance.

Most of us recognize that these potential problems as possibilities. Unfortunately the randomness of some of these disasters lulls some organizations into a sense of false security-"that's not likely to happen here." However, if proper preparations have been made, the disaster recovery process does not have to be exceedingly stressful. Instead the process can be streamlined, but this facilitation of recovery will only happen where preparations have been made. Organizations that take the time to implement disaster recovery plans ahead of time often ride out catastrophes with minimal or no loss of data, hardware, or business revenue. This in turn allows them to maintain the faith and confidence of their customers and investors.

Disaster Recovery Planning is the factor that makes the critical difference between the organizations that can successfully manage crises with minimal cost and effort and maximum speed, and those that are left picking up the pieces for untold lengths of time and at whatever cost providers decide to charge; organizations forced to make decision out of desperation.

Janco suggests an alternative. First, sufficient data (including application software) is used to re-host the application and users are reconnected to the recovery platform where they can proceed with order taking, email, and other functions. At the same time, more and more of the production system’s historical data is recovered.

Such a strategy has the potential to abbreviate time-to-recovery by making critical application functionality available to workers sooner, enabling work to continue almost immediately after an
interruption event occurs and while the impact of the event is being reduced.

This strategy has enormous potential to improve business continuity strategies without significantly increasing their costs.

Many parts of Europe forbid some data from being transmitted or stored outside of the country. Canada also has some rules that prohibit some data being stored in the United States due to the U.S. Patriot Act's provisions that let the federal government examine corporate records.

It's important to note that the legal issues are local to where your customer resides. You have to understand the laws and make sure that personally identifiable data and some financial records are kept local if required by the law.

This could be an issue as cloud computing systems become more distributed. Indeed, while the primary facility may be in-country, the failover site, or perhaps the site used when the primary site is under maintenance, could be across the border and, thus, noncompliant.

• Identify all critical applications and servers. Include ancillary systems like domain servers.
• In collaboration with business management and technical experts, set recovery objectives (RTO and RPO) that strike the right balance between risk mitigation and practicality.
• Create a well-defined IT disaster recovery plan, and update it at least annually. Include allowances for locating and activating the right people.
• Test your recovery process at least monthly. Choose the most critical servers, not just the most convenient.
• Use test results to update your IT disaster recovery plan.
• When reviewing potential solutions, include the recovery process a part of your evaluation. Test not only the technical backup capability, but also the complexity of the recovery.

The challenge comes after the report details the long list of tragedies that last year's deadly hurricane wrought, including more than 1,330 deaths and $96 billion in property damage. In terms of communications, 38 centers that normally handled 911 calls failed, while 3 million customers lost phone service.

The report urges a wide variety of players to build this new culture, including myriad federal agencies and tens of thousands of state and local emergency first responder agencies. And it calls on private citizens and the private sector to take part.

Most good disaster recovery together with contingency plans with creating a good solid backup from data. Although systems and applications will be reinstalled and reconfigured, data should not be rebuilt out of nothing. The key to that has a good backup is to ensure the data is correct and will be successfully restored. This is not always as easy considering that it seems. One company had this kind of issue. Their backup administrator wouldn't correctly follow procedures while he thought he was doing a backup, he actually was not writing anything. When they tried in order to a database, they discovered all the tapes ended up blank.

Here are a few of the things that can break with your data and therefore the backup requirements that ought to be addressed:

• Accidental or malicious deletion of critical data - Requirement that provides to be able to quickly and easily bring back individual files and version.
• Data that is wasted or corrupted over time - Requirement to jiggle back individual records to renovate database corruptions. The ability to get better data from any previous point in time, and have it as granular as you can.
• A crashed disk - Requirement to recover a disk volume is special than recovering a individual file, but it should be done just as fast, and with automation to keep operational disruptions to a minimum.
• A server failure - Requirement recover operations when replacing a broken server may well be complicated by the desire to install different drivers over the new system if the hardware seriously isn't an exact match. It helps to give the capability to move the required forms workload to a standby server (with unique hardware) or virtual server while the system is being swapped out or repaired.
• A local or regional disaster - Requirement once you lose an entire work to fire, flood, and / or other disaster, have a pre-existing copy of your you important information in another location that is definitely outside the disaster sector.
• Remote offices and part offices - Requirement to experience a process in place to revive with minimal technical sustain as remote and branch offices often will not have the luxury of acquiring an on-site technical resource that can assist in backups and restores.
• Resource-intensive backup processes - Requirement frequent or continuous backup that is not resource-intensive.
• Security breaches - Obligation to secure data. When ever moving data between websites, it needs to always be protected from potential security measure breaches. A breach of data security, whether actual damage is over or not, can be devastating to all your company's reputation, as dozens of substantial enterprises and government agencies have found a lot.

A lightning strike knocked out servers at Amazon's only European data center and the provider has warned some of those affected face delays of up to two days before they get back online.

Amazon has told its EC2 customers in Europe some of them could face outages of as long as 24 to 48 hours as the cloud provider struggles to recover from a lightning strike that disrupted power supplies to its Dublin, Ireland data center. It took 3 hours to recover the first of the affected instances last evening European time (midday Pacific Time) and after almost 12 hours a quarter still remained offline, with knock-on effects slowing their likely recovery time.

Many industry leaders expect DR to be one of the most compelling use cases for cloud-based storage, which has matured from a poorly-understood technology to a sought-after solution. In fact, over 40% of enterprise datacenter managers recently reported that they either have or plan to deploy some form of cloud storage by the end of this year. Most business-critical applications are protected by some amount of off-site backup today, but many firms require more advanced DR capabilities in order to satisfy industry compliance, risk mitigation, or business partner requirements - they struggle, however, to justify the capital and operating costs required to implement them.

Digital content serving, video surveillance, and medical image archiving are some common data use cases for cloud storage which demand strong protection and security, and cloud storage vendors are quickly adding more advanced functionality for additional data types. However cloud storage is implemented, it demands a reliable, efficient, and high volume WAN interface. Any DR strategy which includes cloud-based storage will clearly benefit from maximizing capacity and performance of the WAN infrastructure.

In the world of data recovery, the data is the easy part, the recovery can be hellish, and IT administrators are the ones commissioned with connecting the dots. Enterprises laid up for extensive periods of time due to IT knockouts do not have a glittering record of surviving, so there's more than a modicum of pressure involved here. The National Archives and Records Administration reported in 2010 that 93 percent of enterprises whose data centers were down for 10 days or more due to a disaster filed for bankruptcy within one year of the disaster.

The term "data recovery disaster" defines a situation in which an extended power outage forces an enterprise to recover its data and files from an alternate location - whether that is within the enterprise's physical system or in a cloud backup and recovery service. A short-term power outage or failure of an individual server, or even a rack of servers, isn't generally considered a data recovery disaster.

Given the human tendency to look on the bright side, many business executives are prone to ignoring "disaster recovery" because disaster seems an unlikely event. However Janco has found that over one third of all enterprises have had to activate their Disaster Plans in the last few years.

Business Continuity Planning (BCP) suggests a more comprehensive approach to making sure you can keep the enterprise going and meet it business objectives. This goes beyond the enterprise computers, networks and data bases.  However, the two terms are married under the acronym DR/BC or DRP/BCP. At any rate, Disaster Recovery Planning and/or Business Continuity Planning facilitate how a company will keep functioning after a disruptive event until its normal facilities are restored.