Disaster Recovery Workflow: Can You Respond and Resume?

If defining your Business Continuity Program is putting down its foundation and conducting a proper Business Impact Analysis is framing in the walls, then the process of creating your Recovery Workflows is like installing your mechanical, electrical, and plumbing. It’s what supplies utilities to the users, it’s highly technical work, and if it’s done correctly, it will be completely out of sight for the people that use it.

So, what are Recovery Workflows? As the name suggests, they are mapped, ordered work processes for recovering systems, applications, and Business Processes. The most common-sense example of this is the classic Disaster Recovery Plan with its detailed, ordered checklists of tasks to perform to recover an application. However, Recovery Workflows are not just for dealing with Disaster Recovery and the nuts and bolts of reestablishing technology. Recovery Workflows need to look at the business as a whole and account for the vital components of Business Processes beyond just the applications that the business uses. Recovery Workflows need to look at people and the way that they get work done, and then lay out how those people can get back to work after some sort of business interruption.

“Start where you are. Use what you have. Do what you can.”

Arthur Ashe

Honestly, many businesses start their Business Continuity Program by looking at Recovery Workflows by creating an IT Disaster Recovery Plan, and if they don’t know where else to begin, that’s not an unreasonable starting point. Generally, people have a gut feeling for which applications are most critical to the business on a daily basis, and they recognize the importance of creating Recovery Workflows and IT Disaster Recovery Plans to ensure those applications can be recovered. That is good, reasonable, necessary work, and being able to recover critical applications is an essential part of a successful Business Continuity Program. Many businesses will even go so far as to create recovery plans for dozens or even hundreds of applications, outside of having a formalized Business Continuity Program.

However, looking at just business applications can be a bit of a trap. There are many, many things that overall Business Processes are dependent upon, are not simply part of an IT application or service. Businesses that focus solely on creating IT Disaster Recovery plans will miss the bigger picture and they may not be providing the business what it truly needs to recover from an incident, even though the vital applications themselves can be recovered. Those need to be discovered, and their recovery needs to be tested.

“People are always looking for the single magic bullet that will totally change everything.  There is no single magic bullet.”

Dr. Temple Grandin

For example, let’s say that you have a customer call center where a dozen people handle all your incoming sales calls. You have two critical applications for this group: one critical application routes the phone calls to the customer service reps, and another application is what the reps utilize to pull up customer account information. Simply looking at those two applications and ensuring their uptime through creating IT Disaster Recovery Plans really isn’t enough to make sure that these people can still work. If these dozen people work in a physical call center, then we need more than just two applications to do their job — they need a dozen workstations, a dozen desk phones, a dozen headsets, and a dozen places to sit. They need drinking water, bathrooms, and a place to take breaks. They need physical security, they need connectivity, and they need security for their data. They’ll need e911 services. They also probably need access to the same things that every other employee needs access to, like email, the web, and your corporate Intranet. If your call center is virtual, then your people will have different needs, along with some of the same needs. They will still need workstations and headsets, but they might need laptops instead of desktops, and they might need docking stations and external monitors. They’ll need different e911 services.  Working from home they will need reliable Internet connections, and those connections will need some type of enhanced security beyond what their local Internet providers will give them. If your current Recovery Plan for this physical call-center is to send people home to work, then you will have to meet the needs of both kinds of users to ensure that your Recovery Workflows are viable. (You also need to test and make sure everything works the way you want it to.)The best way (and really the only way) to gather all that data from the business is to do a proper Business Impact Analysis (BIA). When properly done, a BIA will enumerate the needs of the business beyond just a couple of applications. It will uncover the vital parts that make up the whole of Business Processes so that all those parts can be accounted for. A proper BIA will also help to illustrate workflows beyond what happens in a single department or business unit by showing interdependencies between departments.

Once you have your BIA data in hand you can create more viable Recovery Workflows. You can create workflows that target the needs of entire Business Processes, and that account for interdependencies between departments and service agreements with customers. You can also create workflows that prioritize IT Disaster Recovery and other recovery work efforts based on the true needs of the business, rather than an arbitrary estimation by the IT department. One truly feeds into the other. 

“Just remember, you can’t climb the ladder to success with your hands in your pockets.”

Arnold Schwarzenegger 

Recovery Workflows really are at the core of creating departmental Business Continuity plans, and honestly, they can be the most time-consuming and technical part of the planning process. When I ran the Business Continuity Program office at a major manufacturer, I created a project template for developing departmental Business Continuity plans that I could use for all areas of the business. The project timeline included training people in on how to use the BC Management system, creating employee contact lists, performing a BIA, writing departmental Recovery Workflows, and then getting management’s sign off on everything. For all the different things that were included in that plan, 60% of the project timeline was allocated to creating those departmental Recovery Workflows. Everything else was just small fractions of the overall project timeline, regardless of the department.

“Success is the result of small efforts, repeated day in and day out.”

Robert Collier

Once they are created, it’s important to remember that your Recovery Workflows need to be maintained.  Technology changes.  Staff is hired or moved, and sometimes moves on.  The company grows or shrinks, and company needs change right along with it. Events sometimes come along that fundamentally change the way you do business forever.  And, any of those things can happen at any time.  It’s best to put policies in place to make sure that your Recovery Workflows are reviewed at least once a year, just like your BIA data. 

Since they can be so time consuming, naturally there are tools out there to help create and maintain Recovery Workflows.  In addition to providing consistent formatting and helping to integrate data into plans from different sources, tools can make it easier to spread changes across multiple workflows at once.  That means that if you upgrade some critical application that twenty different departments use, you won’t have to manually update twenty separate Recovery Workflows. Tools can both improve the quality of plans and workflows, as well as decreasing the effort involved in creating and maintaining them.

Creating Recovery Workflows might seem like a lot of work, and maintaining them might also seem like just another task for people that are already stretched thin. But, Sayers is here to help.  Our Business Continuity Maturity Assessment Tool can help show you what you should be putting in your Recovery Workflows, how well-defined your Business Continuity Program really is, and where you might need a little help.

---