Perhaps I’m just a curmudgeon (a crusty, ill-tempered old man), but it irks me when someone uses the term “Business Continuity” exclusively to refer to IT planning. Perhaps I’ve been in this industry too long. I remember when IT planning was referred to as “Disaster Recovery”, and only business operations used the term “Business Continuity”. Suddenly (or at least it seems sudden to me) IT specialists are throwing around the term Business Continuity as though they invented it – and as though everyone should understand what they mean.
Is Business Continuity an appropriate term for everything to do with recovery from, or response to a business disruption – to include both technology and operations?
Let me take a step back for a moment to admit that I’ve been a BCM industry advocate for integrating BC (business operations) and DR (technology) planning for many years. I have been in the industry long enough to remember when IT Disaster Recovery plans were routinely created without input from ‘the business’ (the people who actually make money for the organization). In that era – largely based on mainframes and midrange computers, and eventually ‘client-server’ infrastructure – DR plans were an all-or-nothing proposition. You either had a working data center or you didn’t. If the data center was disrupted (fire, power outage, flood, etc.) the Disaster Recovery Plan was the only alternative. You packed up your people and sent them – and your backup tapes – to a 3rd party recovery site. Anything short of smoke-and-rubble was viewed as an operational outage – not worth the cost of invoking the DR plan.
Disaster Recovery used to be defined as “the processes, policies and procedures related to preparing for recovery or continuation of technology infrastructure critical to an organization after a natural or human-induced disaster” (from Wikipedia).
But all that has changed. First, business operations – in our 24/7, global business environment – began to demand shortened Recovery Time Objectives (or always-on availability). Second, server virtualization made operational incidents fewer and easier to recover from. And now, cloud computing has created the potential for widespread high availability of critical application and systems.
Apparently “Disaster Recovery” is no longer sufficient (or in some organizations, necessary). IT planners have commandeered the term Business Continuity to apply to IT highly-available cloud recovery processes.
The old BS25999 standard defined Business Continuity as the “strategic and tactical capability of the organization to plan for and respond to incidents and business disruptions in order to continue business operations at an acceptable predefined level”. That seemed straight forward; “business disruptions” (not IT disruptions) was the operative term.
But now the new ISO 22301 standard defines Business Continuity as the “capability of the organization to continue delivery of products or services at acceptable predefined levels following a disruptive incident”. Not a mention of ‘business’ anywhere.
So, have we reached a theoretical “post-DR” point (to coin a phrase)? Do we no longer require separate terminology to differentiate between technology plans and business operational plans? Are we all – IT and business planners alike – able to cooperate under one big umbrella?
It depends on whom you ask. I’ve interviewed several planners on both sides of the planning realm. They have allowed me to quote them, but only anonymously (you’ll understand why). They disagree on whether the big tent of post-DR Business Continuity is viable:
“We’re told which systems and application are critical to the business, and we plan to maximize our recoverability of those priorities. They give us RTO’s to shoot for, but we don’t always have the money to make that happen. We ask for budgets and we do the best with what we can. We estimate RTO’s for those things we can’t recover quickly. The business has to adjust accordingly,” stated one mid-size enterprise IT recovery specialist.
“IT has only an arms-length understanding of what the business needs. We can tell them which apps are critical, but we have to leave it up to them to assure that everything – the data, the upstream applications they rely on, our ability to connect – is included in their planning. We have their assurances, but no means of verifying what they say they’ll deliver, since they don’t include us in their tests,” said a business-side BC manager.
Surely these are a very small sample. There are as many variations as there are organizations. Perhaps some larger enterprises have both the mandate and the finances to meet all-encompassing Business Continuity objectives. But there are still many businesses (I hear from them frequently) where only IT planning has a budget. There are organizations where the business-side is still moving the deck chairs on the same BIAs and plans they began with a decade or more ago. There are many organizations where the IT and business-side planners have never spoken.
Have we reached the ‘post-DR’ world where ‘Business Continuity’ should be the big tent for IT and business recovery? Or do we still need separate umbrellas? Unfortunately, now that IT has appropriated the Business Continuity term, the business-side may have to come up with a new umbrella term.
Better yet, maybe it’s time for two new terms: “Technology Recovery” for the IT side, and “Operational Recovery” for the business side. Both should work together toward a common goal of Business Continuity.
Unless and until IT and ‘the business’ work together as equal partners in the development of comprehensive Business Continuity, we haven’t moved into a truly ‘post-DR’ world. As long as the two extremes see themselves as adversaries, they are unlikely to reach true Business Continuity objectives. As long as they fight separately over the same budget dollars (and we all know who usually wins that battle), they will never truly be partners in organization recoverability.
