Did you ever eat alphabet soup as a kid? Maybe you still do…anyway, I remember that I would try and try to spell words and make sentences, all to have the letters swirl around and become confused all over again and again. It was great eating, but frustrating if you’re trying to organize your bowl of soup.
So, why am I talking about alphabet soup and how does this apply to Business Continuity Management (BCM) or Information Technology Disaster Recovery (DR)? In case you haven’t noticed, we BC/DR folks live in a world of regulatory alphabet soup. Did you know there are well over 100 regulations, methodologies, maturity models, guidelines and laws – what I’ll call, “authoritative sources” that have something to say about BC or DR? They are regional, country-specific, by industry, by topic, practical advice, best practices and more. I don’t know about you, but it makes my head hurt thinking about it, let alone trying to comply with them!
I’m not making light of these sources in any way because they serve their own purposes and some excellent thought and preparation has gone into them, but this is my current bowl of alphabet soup – ISO22301…BS25999…HB292…NFPA1600….ITIL…NIST…Z1600, well you get it. So, my quandary as a business is how do I determine which of these sources to comply with? Which of them actually apply to my business? How can there be so many varied sources, and are they really that different? Do they all say the same things and how do I coordinate them all?
Our friends at Disaster Recovery Journal have done a great job to compile and coordinate these sources for our reference (for example, see http://www.drj.com/tools/tools/dr-rules-and-regulations.html), but it still begs the question – which sources do I comply with and why? Once I’ve figured that out, what if there are conflicts between the sources and how do I prioritize them? Further to that point, how do I institute these requirements into my existing program? And if I do, will these authoritative sources provide me with good guidance or are they just a checklist of requirements? Even scarier is what if I’m audited? How do I prove my program is compliant? Finally, how do I explain and justify this to executives and business partners? (this is an entirely different blog…)
These and others are good questions that are being asked in BC/DR programs of all levels of maturity. It can be daunting to weed through the morass and put together a coordinated program that you can actually manage, so my next blog will give some practical guidance on how to do just that.