What happens when an organisation is attacked? Is a Business Continuity Plan and Disaster Recovery Plan the same?

So do you have a BCP or DRP?

Business Continuity Planning (BCP) is an ongoing process of risk assessment and management with the purpose of ensuring that the business can continue if risks materialise. These risks could be from the external environment (over which you have no control, such as power failure) or from within your organisation, such as deliberate or accidental damage to systems. Business continuity is not just concerned with disaster recovery; it addresses anything that could affect the continuity of service over the long term, such as staff shortages in specialist areas.

BCP is all about understanding the business and establishing what is vital for its survival. If a mission statement and key supporting aims exist, these indicate where the organisation is focused. It is on mission critical activities that BCP must focus.

Your organisation has many dependencies, both internal and external, that support the mission critical process and functions. These can include providers, customers, other stakeholders, IT systems, and manufacturing processes, all of which must be identified at an early stage. You should involve representatives from these key dependencies who will add value to the process.

There must be a cultural readiness to accept BCP. There should be an education and awareness programme to ensure organisation-wide understanding and adoption of the plan, covering internal and external stakeholders.

Business Impact Analysis (BIA) Not heard of this?

BIA is the step between a BCP and a DRP. A Business Impact Analysis (BIA) predicts the consequences of disruption of a business function and process and gathers information needed to develop recovery strategies. Potential loss scenarios should be identified during a risk assessment. Operations may also be interrupted by the failure of a supplier of goods or services, or delayed deliveries. There are many possible scenarios which should be considered. The BIA should identify the operational and financial impacts resulting from the disruption of business functions and processes. Impacts to consider include:

• Lost sales and income.
• Delayed sales or income.
• Increase in expense (labour cost, outsourcing).
• Regulatory fines.
• Contractual penalties.
• Client dissatisfaction or defection of client to alternative organisation.

Risk Assessment

Risk Assessment is part of the BIA and it is the assessment of the impact of a disruptor on the business. Consider the impact an incident could have on your relationships with customers, the surrounding community, and other stakeholders. Consider situations that would cause customers to lose confidence in your organisation and its products or services.
As you conduct the risk assessment, look for vulnerabilities—weaknesses—that would make an asset more susceptible to damage from a hazard. Vulnerabilities include deficiencies in building construction, process systems, security, protection systems, and loss prevention programs. They contribute to the severity of damage when an incident occurs.

And finally, Disaster Recovery Plan

Creating a Disaster Recovery Plan is a compromise and while people are aware of best practices, they face issues related to cost. When best practices are pitted against cost, cost needs to be the second and not the first priority. Even more important though, is that capabilities need to be matched to expectations. Responding to a disaster is an exception, but preparing for it should not be a burden, but instead be integrated with day-to-day priorities.
The Disaster Recovery Plan needs to represent all functional areas within IT prior to, during, and after a disaster. It needs to include applications, networks, servers, and storage.

Contingencies, such as "what-if" scenarios, should be considered as part of planning process. Decisions need to be made regarding levels of disruption that will constitute a disaster, downtime, and loss tolerances.

Keep the Disaster Recovery Plan current

Disaster Recovery planning needs to be part of the day-to-day operations of the IT environment and even though it is an exception, it should always be at the forefront of people's minds. Once the Disaster Recovery Plan is created, it needs to be maintained and updated every time an element within the IT environment changes. The dynamic nature of IT environment means that the Disaster Recovery Plan will fail if the management of the plan is not part of change management.

Test the Disaster Recovery Plan

The Disaster Recovery Plan needs to be tested regularly to ensure the business can complete recovery successfully and in a timely fashion. Disaster Recovery testing is a major challenge for most IT departments, but if recovery has not been tested all the way to the application level, it is very likely that problems will occur.

Even though a Disaster Recovery test is a major operational disruption, it shouldn't simply be treated as a pro forma exercise, but needs to include true end-to-end testing all the way to production. The focus needs to be on recovering applications rather than servers since, with today's complex applications, client servers, and web-based multi-tier applications, the components reside on multiple servers thus there are interdependencies between these. If disaster recovery has not been tested all the way to the application level, it is very likely that problems will occur.

The philosophy for Disaster Recovery testing needs to change. Basically the approach used for software quality testing should be adopted, where finding bugs is a positive thing. Finding problems in Disaster Recovery is equally positive as long as these issues are resolved to eliminate problems during a real disaster.

Set realistic recovery objectives

Frequently, organisations have established objectives and prioritised servers and applications in accordance with Disaster Recovery policies. However, upon an objective examination of Disaster Recovery capabilities and resources, it turns out that these goals are not attainable. Thus, it is important to set realistic Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO).

In regard to the RPO, when does the clock start ticking and what tolerance is permissible for an outage? As for the RTO how current is the data prior to the disaster?
These are the key matrix items that need to be determined and supported. It is important to examine whether the infrastructure can support the goals.

If you have any questions or concerns about your organisation's BCP and DRP, or want to know more about what you can do to protect you, your staff, and your organisation, contact your Inside Account Manager.