By Paul Kirvan, CISA, CSSP, FBCI, CBCP
If your organization has a help desk or similar IT support function, chances are it's not protected by either a disaster recovery plan or business continuity plan. Given the importance of help desks, it's surprising that they aren't usually covered by emergency plans. Perhaps the thinking is that the help desk -- which probably uses proprietary or homegrown issue tracking and management software -- will be automatically covered by the technology disaster recovery plans. But what if it's not? And what happens to the help desk staff in a business-disrupting incident?
For help desk and other technical support entities, the disaster recovery plan process requires several steps. These include project initiation, risk assessment, business impact assessment, strategy development, plan development, plan exercising and maintenance, emergency communications, awareness and training, and (if necessary) coordination with public authorities.
In this article and associated help desk template, we'll examine the issues that should be addressed when preparing and deploying a disaster recovery plan for a help desk.
HELP DESK TEMPLATE: TABLE OF CONTENTS
>> Making disaster recovery a priority for the help desk
>> Important points to consider when creating a disaster recovery plan
>> Help desk disaster recovery template components
>> Free help desk template for disaster recovery planning
When it comes to help desks, business continuity and disaster recovery are probably not even on the radar, despite help desks being a potentially important part of an IT department's disaster recovery response. Should there be a separate disaster recovery activity for the help desk, or should the help desk simply be part of an established IT disaster recovery program/plan? If the IT organization is limited to one site, with operations during normal business hours, its help desk could be part of an IT BC/DR plan. However, if the IT organization spans several countries and supports 24/7 operations, the help desk function will likely be more critical and complex and, as such, ought to have its own plan.
Further, it's a good idea to have a separate help desk plan if the unit's activities extend beyond IT. For example, suppose the help desk function includes a separate Web site for posting inquiries and reporting problems. And suppose the help desk also provides access to employee information such as special forms, and facilitates inquiries to management with suggestions or critiques. Finally, suppose the help desk operates 24/7, and serves a global workforce. A broad-based help desk organization like the one we've described ought to have its own BC/DR plan, especially as it will no doubt have several employees on staff. As is often the case with any business activity, determine how the activity supports the organization, and its value is to the firm.
Assuming a unique help desk BC/DR plan is indicated, management has several options, such as business continuity software, templates, checklists, or consultants. If the help desk function is primarily IT-focused and not a large global operation, IT managers can incorporate help desk components into their overall BC/DR plan, adjust emergency response activities to include the help desk, add contact information that's relevant to the help desk, and regularly exercise the IT disaster recovery plan, making sure to include the help desk. As we have with similar disaster recovery templates in the past, our goal is to simplify the process for developing help desk disaster recovery plans. We'll adapt a more or less standard disaster recovery plan template for the help desk disaster recovery plan template.
Before you get started creating your help desk disaster recovery plan, keep the following points in mind:
- Take the process seriously.
- Keep the process simple. To keep the process simple, we suggest checking out Ready.gov (part of the Federal emergency Management Agency site) and look at the emergency plan development information available at that site. Less can definitely be more in this situation, unless the help desk is tightly integrated within IT and it may be better to leverage existing IT DR plans.
- Use standards as a starting point. Almost two dozen business continuity standards are available worldwide.
- Limit content to actual disaster response actions. Assuming you're creating a plan to respond to specific incidents, include only the information needed for the response and subsequent recovery.
- Test your disaster recovery plan. Once the plan is complete, test your disaster recovery plan at least annually to ensure that the documented procedures make sense in the sequence indicated.
- Be flexible. A single template may not be universally applicable to help desks, especially if your organization has many locations, multiple data centers and multiple help desks; you may want to consider other templates, software or consultants.
Next, we'll examine the structure and content of the help desk template, indicating key issues to address and activities to perform.
- Initial data: If you've identified various help desk and non-help desk personnel to contact in an incident, position their contact data at the front of the plan, so you won't have to waste valuable seconds paging through a lengthy document.
- Revision management: Have a page that reflects your change management process.
- Purpose and scope: Provide details on these attributes, as well as assumptions, team descriptions, a list of terms, and other background information.
- Emergency instructions on how to activate the plan: Provide data on circumstances under which the plan will be activated, including outage timeframes, who declares a disaster, who should be contacted and response procedures to be used.
- If the IT department has a disaster recovery policy, be sure to include the information; this is also a good place to use standards documents as references.
- If possible, provide step-by-step procedures, as these are easier to follow than broad general statements.
- Describe how often the plan is to be reviewed and updated, and by whom.
- Assuming a situation has occurred, have steps identified to address it; these can be in the form of checklists (useful to keep track of scheduled and completed tasks) and flow diagrams that provide a high-level view of response and recovery.
- Information needs to be gathered before officially declaring a help desk disruption; this includes damage assessment data and first-hand reports from staff and first responders (if needed); convene meetings as soon as possible with key IT emergency team members to evaluate the facts before proceeding to a declaration.
- Once initial facts on the incident are obtained, the plan should list actions to take when it becomes necessary to declare a help desk disaster.
- Once the situation has been brought under control, subsequent parts of the plan should provide instructions on recovering help desk operations, relocating to an alternate site and related activities.
- Detailed appendixes are provided at the end of the template; these include lists and contact details on all IT and non-IT emergency teams, primary and alternate help desk vendors, alternate help desk locations, and other relevant information. It is very important to keep this information up to date.
The process of developing a disaster recovery plan for help desks should be a relatively easy process. The keys to success include defining step-by-step response and recovery procedures, validating these activities through tests, and keeping the plan up to date.
Click here to download the free help desk template.
About this author: Paul Kirvan, CISA, CSSP, FBCI, CBCP, has more than 20 years experience in business continuity management as a consultant, author and educator. He has been directly involved with dozens of IT/telecom consulting and audit engagements ranging from governance program development, program exercising, execution and maintenance, and RFP preparation and response. Kirvan currently works as an independent business continuity consultant/auditor and is the secretary of the Business Continuity Institute USA chapter and can be reached at email@example.com.
This was first published in January 2011