1300 130 447
internal and external
Source - HDI Report
About the Knowledge Base
Search all the Knowledge Base
Testimonial: I have found that the new HDAA Knowledge Base reduces the time it takes me to research industry stats & reliable information for the ITSM sector. It’s easy to use search functionality encompassing KCS principles, helps to filter & tailor my searches more accurately & there are numerous new services now available through the website. Every time I return to the site there is new information published. Very impressive.
Chris Powderly, Support & Services Manager, Allens
supportworld , service management , disaster recovery , business continuity , business continuity planning
No Result Found
As technology has become more pervasive within almost every type of business, the concept of having a concrete plan to respond to problems becomes more critical. In the past, “disaster recovery” was primarily a business function that focused on things that could bring a halt to the business, keep people away from their office, or make the site inaccessible. These events were typically “acts of god,” like severe weather, floods, or something similar.
Technology has changed all of that. Now, in addition to natural disasters, there are man-made events that can seriously impact the ability of the business to function. These could be accidents, like a construction crew cutting the network fiber to a site, a pipe bursting in the computer room, or even someone inadvertently shutting down a critical piece of equipment. Other man-made events are more nefarious, such as denial of service (DoS) attacks, malware, viruses, and ransomware. These types of attacks commonly come from outside, but it’s not uncommon for them to originate inside the walls of the company, from a disgruntled employee.
Ransomware in particular has been in the news frequently in recent months, from attacks on health systems to local and state governments. These events can effectively shut down a business as it tries to recover.
As a result, the concept of Business Continuity is included in the latest ITIL release. If you look at many IT job postings, you’ll see that it is often being included as a key responsibility.
Despite that, many organizations still struggle with the idea of how to build an effective business continuity plan (BCP). Hopefully, this article will help lay a basic foundation.
Despite everyone recognizing that recovery from a business-halting event is important, it may still be necessary to sell the idea of having a formal business continuation process. To that end, you may need to build a business case that quantifies the impact of these events. As with most business plans, the most effective approach is often driven by cost.
Obviously, there are levels of response, based on specific events. You can choose to focus on the worst-case scenario, meaning the complete shutdown of the business—this would involve payroll costs, real estate costs, loss of revenue, and so forth. But often the worst-case scenario is harder to picture, and the reality is that while it’s possible, those type of events are few and far between.
A better approach would be to simply look at one type of event. For example, since there are plenty of examples of ransomware attacks and the costs they incur, focus on that type of scenario. Lay out the tangible costs—the ransom amount, cost of lost productivity, costs of lost business, and so forth. Then list the intangibles, such as the public relations impact or the potential effect on the stock price.
Explain how this type of attack works—that it can simply be an innocuous email and someone clicks a link—and how this malicious software can travel through your network and attack anyone who is online. Point out that these events get worse over time. The longer the downtime, the more costly; the longer the delay in response, the more likely that the infection will continue to spread or the cost to recover the data may go up. The point is not to frighten anyone, but rather to help develop a healthy respect for what can happen if there is no documented response.
Explain what the approach will be (as documented below) and how important having leadership sponsorship is to the success of the plan. Once you have the go-ahead, you can move on to the next step.
The first step is building the BCP teams. These can be broken into three different sets of participants:
For each group, there should be a distribution list and a call tree. Keep in mind, in a continuation event, not everyone may have access to email or voicemail, so a clear communication plan is necessary. The distribution lists can take a number of forms, and for best coverage using more than one is a best practice. This can be done via email, voicemail, text message, social media, or direct calls to someone’s mobile or home phone.
This is where the call tree becomes effective. Instead of one person trying to reach out to entire teams, a tree structure is created where specific contacts call others, who in turn call their contacts, and so forth. This is a straightforward means of contacting everyone that should work across almost any sized organization; in larger, more complex environments it may be possible to automate the notification process.
While some people may cross from one to another, the makeup of the three teams is different, as they have different functions.
The BCP Committee is made up of individuals representing key functions. These should be people who have the authority to make decisions that impact their areas of responsibility, preferably managers or their delegates. Each of these individuals will own their functional areas’ specific response to a BCP event. There should be two people designated as the overall decision-makers for the BCP: a primary and an alternate. Additionally, it often makes sense to have two people assigned as document owners—a primary and an alternate—who are responsible for maintaining the actual contents of the plan.
The BCP Response Team is made up of people who are activated in the case of an event. Using the primary/alternate model, key sites would have specific representatives, key functional owners would be represented, and the overall decision maker would be in this group as well to make on-the-spot decisions as events unfold. There are really three areas that need representation: critical sites, critical applications, and critical vendors. I’ll discuss defining these areas later.
Finally, BCP Consultants are those individuals who either need to be kept informed of progress, such as members of senior leadership not on the above teams. Other consultants might be people that have specific skills or knowledge that may need to be called upon depending on the type of event, or it’s duration, or other predefined criteria. This could be other IT partners, business leaders, or even vendor representatives.
One of the jobs of the BCP Committee will be to create definitions for what is considered critical. This will vary depending on things like the size of the business or the industry.
It shouldn’t need to be said, but it’s vitally important that critical business data is backed up, either via an on-premises application or through a reliable vendor. This data should be securely moved off-premises to a secure space on a regular basis. It should be isolated from the normal network to avoid corruption in the case of targeted attacks.
For each of these critical areas, part of the documentation should be a time-based checklist. This details what happens at each stage of an event. There should be clearly documented steps that occur when the BCP is activated.
In the case of natural disasters, sometimes there is warning—a hurricane or severe snowstorm, for example. In that case, the plan could be activated ahead of the event, at Day minus x, to prepare or harden a site, move a function, coordinate with vendors, etc.
If there is no warning, then the plan is activated, and the checklist provides direction on what needs to happen, in what order. For instance, upon activation, one of the first steps is getting everyone together via the call tree. The team can assess the severity of the event, and based on that, make further preparations.
From there, the plan documentation should make an attempt to lay out what needs to happen over time. This is where specific actions are documented if service is interrupted for a day, several days, a week, two weeks, a month, all the way to a site, application, or vendor being unrecoverable. This time-based documentation should estimate the impact to the business and attempt to detail how much functionality can be returned at each step of the plan.
A key function of the BCP committee is to review and keep the plan up-to-date. At minimum, there should be a quarterly document review that identifies changes. If the plan is kept current, these quarterly meetings shouldn’t take much time, only a quick evaluation to determine if site contacts have changed or if any of the applications or vendors need to be updated.
Finally, a best practice is to have regular practice in implementing the BCP. This means testing the distribution lists and call trees and documenting the response. It means that you need to hold regularly scheduled simulations where the BCP Response Team works through a scenario. This should happen at minimum once a year, and it would be better to have it twice yearly. These practice sessions would provide a unique scenario—some I’ve participated in were fun exercises like a Zombie Apocalypse or realistic simulations of a ransomware attack. Use what’s popular or currently in the news, or look at events that could be specific to your region (hurricanes, earthquakes, etc.). This allows the team to work through the checklist and document areas for improvement.
This is a lot to take in, but the reality is this article only scratches the surface of building a business continuity plan. If done properly, a BCP can be invaluable even in the case of minor incidents and a huge benefit in the unfortunate event the full BCP has to be activated. Being prepared is the key to success or failure.
Mike Hanson has many years of experience with IT leadership, having managed several different aspects of technology over the past 30 years. Today, he serves as global operations manager and leads the asset management and fulfillment teams for Optum, Inc. He has been involved with HDI for many years, as both a local chapter officer and as a past chair of the HDI Desktop Support Advisory Board. Follow Mike on Twitter @Mike_MiddleMgr.
No Result Found
- Contact Us
- IT Membership
- Support Centre Association
- Comparison Guide
- Price Guide
- Membership Conditions
Training & Workshops
- Training Courses
- Recent Workshops
- Cancellation & Transfer Policy
- ITIL Training
- ITIL Foundations
- Support Centre Consulting
- Service Desk Consulting
- Help Desk Consulting
- Media Kit
- Update your details
- New account
© Copyright HDAA. All rights reserved.
HDAA - Energising the Service & Support Profession
Help Desk Association Australasia Pty Ltd trading as HDAA
T: 1300 130 447 T: +61 (0) 2 9986 1988 F: +61 (0) 2 9986 1330
E: email@example.com W: www.hdaa.com.au A: PO Box 303, Turramurra NSW 2074 Australia
ABN: 20 088 292 755
Our Services: ITIL | ITIL Training | ITIL Foundations | IT Membership | Service Desk Association | Support Centre Association | Support Centre Training | Service Desk Training | Help Desk Training | Support Centre Consulting | Service Desk Consulting | Help Desk Consulting
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
DevOps Foundation®, is a registered mark of the DevOps Institute.
HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.
KCS℠ is a Service Mark of the Consortium for Service Innovation™.
SIAM™ is a registered trademark of EXIN.