Some hints on BS25999-2:2007 - "Business Continuity (BC)"

[Randy]

I know there hasn't been much discussion on this subject, but I figured tossing out a couple of hints for folks interested in it couldn't hurt.

First of all, "Business Continuity (BC)" and "BS25999" isn't about Disaster Planning in the context that we may be used to and does not center itself around IT. BC concerns itself with the "Business" as a whole and the planning necessary for business to sustain itself after a calamity strikes be it flood, fire, labor walkout, financial meltdown, power outage or whatever else can happen in the real life business environment.

The BS25999-2 document does have a couple of glitches in it and the most glaring one is that it is written out of sequence, or not in the order an organization needs to take when planning for the continuation of its operations. (This fact was agreed to by one of the authors during a recent discussion I had with him (This is the person who originally led the development team of BS25999)).

Another small problem is the lack of providing some key "Definitions" in Section/Clause 2. Definitions for key works like "competence" and "exclusions" are not provided. The lack of a defining of what "exclusions" meant in 3.2.2.3 Policy led to some very detailed discussion. In the end "exclusions" used in 3.2.2.2(a) Policy relates to activities determined to be excluded in the "scope"of the BC planning process due to their not being considered as critical activities (clause 2.15). These "exclusions"must be documented in the Policy.

When doing BC and using BS25999 as the template the organization should start at and follow this sequence in the beginning to help guarantee better success:

(1) 4.1 Understanding the organization;

(2) 4.1.1 Business impact analysis;

(3) 4.1.2 Risk assessment;

(4) 4.1.3 Determining choices;

(5) 3.2.1 Scope and objectives;

(6) 3.2.2 BCM policy,

and then follow on with all the other requirements from sections/clauses 3, 4, 5 & 6.

Ok, I'll stop here (mainly because I have to get on a plane)

Feel free to jump in.

 

[Richard Regalado]

A soft launch for BS 25999:2007 was held here in Dubai couple of weeks ago. The interest level is quite high I must say. Lots of participants from financial institutions.

I will share more after Ive completed my Lead Implementor's course.

Cheers and thanks for starting this thread.

 

[john.b]

I was just working on some business continuity planning so I thought I'd add the usual chatty input.

BS versus ISO: I've heard ISO would finally adopt this as their business continuity standard in the next year but Randy would know better than me on this.

BS 25999 versus ISMS (ISO 27001) and ITSMS (ISO 20000): those two standards also contain business continuity requirements, of course less substantial than BS 25999 and not required as organized per BS 25999 specific requirements (just mentioning).

general business continuity versus IT business continuity: BS 25999 really does try to avoid focus on just IT recovery, and emphasizes broader aspects of service continuity, evaluation, planning, etc. but there are other standards that focus more on just IT. ISO/IEC 24762:2008 relates to IT DR recovery and ISO/IEC 27031:2011 covers IT business continuity under the 27000 family of information security scope. I've only read the former and it is a bit vague and unsatisfying.

other continuity standards (than British versions): I've read Australian and Singaporean versions and they were almost identical to BS 25999, which is probably why other countries are probably contesting adopting another British standard into ISO use (but again I'm not an insider). Part of the point is consistently using terminology and applying steps in the same order (as I recall the Australian version switched order of BIA and risk assessment) so implementing the "best" is only one issue, others being who gets to settle arbitrary differences from terminology and such.

business continuity policy: of course Randy is right that 25999 says you determine that last (see prior post) but in an implementation class the instructor (from BSI, for what it's worth) made the helpful point that this could also be an iterative process, so that you lay out some basic policy outlines early on and then finalize these to a complete and revised set later. Whether you called it policy content or not you would need some management directive and commitment to get through an implementation process.

what is "continuity" aside from disaster recovery: too long a question to really answer, but in a nutshell DR is systems recovery and alternative workspace (quite oversimplified), and business continuity includes anything else to assure continuity. Planning uses defined steps to determine impact of disruptions and acceptable limits and time-frames (BIS), and risk assessment related to what might happen (disasters, and whatever else disrupts continuity), and breaks planning into immediate incident reaction steps (emergency planning, fire escape, etc.) and longer term planning for restoration (BCPs, the heart of the system). Anything else could be included: IT related DR planning (back-ups, systems recovery, etc.), alternative site, financial related planning, media contact, communications (process and systems), contingency supplier planning, related capacity evaluation, testing procedures, various related records, contact lists, etc. BS 25999 doesn't really try to spell it all out, and most of it depends on circumstances anyway: company, service, and context (event) related.


Definitely chatty enough, now back to some actual work.

 

[pldey42]

I agree with Randy's overall process steps, but would add that I think they're iterative.

In other words, we start with understanding the organization etc, and once we can see the major impacts of disruption we can define scope, objectives and policy. Then we realize it's all too much work, and go through the steps again to focus on the really big impacts and risks - those that would be impossible to survive. We end up with a tightly-defined scope, objectives and policy, one that we can implement with an affordable budget and in a reasonable timeframe.

Many organizations make two mistakes. First, they define scope, objectives and policy too broadly, work through impact analysis, risk assessment and some planning, decide it's all too big and give up.

Others focus too much upon risk assessment and not enough upon impact analysis. It's true to say that business continuity is what we do when risk assessment and mitigation fails. While we plan for forseeable risks like power failure, pandemic flu and floods, and do our best to avoid them, BC is really about planning what to do if (when?) these things happen.

it might also help to note that BS 25999 identifies three phases of business continuity management: (Step 2 comes before, or at least starts before, step 3 of course.)

1. Incident management - what to do when something goes bang. Covers things like whom to call and how, who decides it really is an incident and not a false alarm? Who gets called out and who gets sent home until the all-clear? How do we get to the DR site? Do we even need IT as much as they like to think, or will pencil, paper and a megaphone work for a while? And who's paying for lunch (sounds daft but even emergency work stops when people are hungry and nobody brought cash with them and the ATM network is down).

3. Recovery (some call it DR) - how do we get back to normal? Do we even want to return to normal, or should we identify a new normal? (E.g. do we want to continue with a data centre that's below the flood plane or should we rebuild somewhere else? How about two data centres instead of the one that just failed catastrophically and almost killed off the entire business?)

2. Business continuity - how do we ensure the business survives until we can effect recovery? What are the absolutely critical processes that must continue no matter what? How? E.g. temporary call centre to replace the one that just got trashed, temporary staff to replace those lost in the incident, maybe extra staff to deal with the immediate consequences of the incident. What are we doing to help those lost or injured, and their families? How do we deal with press and customers, maintain their confidence and not make matters worse?

There is an ISO version on its way - draft was circulated a while ago and it will be interesting to see how long the committee takes to reconcile all the comments, of which I suspect there were rather a lot. The draft I saw was largely compatible with BS 25999, fixed some of its problems (though not the ordering problem Randy mentions) and introduced some new ones. (The worst of these was that, unlike BS 25999, it required a documented recovery plan. Currently, this is not a requirement because until disaster actually hits, it's not possible to plan recovery - and the nature of the disaster often indicates that merely returning to normal would be bad - for example, one hopes that BP's drilling processes will change from the old "normal", having learned lessons from the Gulf; and for Japan there is a difficult debate to be had about meeting the country's current and future electric power requirements.)

Hope this helps,
Pat

 

[Marc]

What's the status with BS 25999 ("Business Continuity")?

What's the status with BS 25999 ("Business Continuity")?

 

[john.b]

Awesome to see this forum back! I'll have lots to say about a few different things since it's back up, and I'll look for the thread on that.

BS 25999 turned into an ISO standard a couple years back, 22301. They just adopted the British version so it was the same, word for word as far as I know, although for years they seemed to have been considering whether to go with a different starting point than that, since there were other business continuity standards out there. They were all sort of similar, as far as I know, except one version (Australian?) had switched the order of Business Impact Assessment and Risk Assessment steps (based on memory, not completely reliable at my age).

Of course people switched over, if already certified to 25999, and there was some uptake of the new ISO version here where I live, in Thailand. It never became as trendy as ISO 27001 had been (information security), or as popular as that stayed due to concerns over security. My company is certified to ISO 27001 and it contains some business continuity requirements, as does 20000 (service management), so a company could draw on 22301 guidance and implement most of all of it within one of those systems, if they were just in it for function. Of course such systems often tend to relate to marketing too, and if so a company with part of the framework wouldn't find it so difficult to go through putting the rest in.

It's more that ISO systems tend to add paperwork and controls burden, more planning testing and update requirements for that one, so beyond direct costs and work one has to evaluate if they really want to stack it all up. It might be a touchy subject but I wrote a pandemic BCP that might be useful to others, which isn't so difficult to research, it's just harder than one would think to pull it together into a decent format with concise content. The virus-based apocalypse is not so easy to really prepare for, since those tend to be misses, and the biggest, worst-case version would take a unique form, but having some research and well-thought-out ideas in place couldn't hurt.