Keeping your BCM policy succinct

• 05 Dec 2019
• Mohan

• Blog
• 0

  Comment

Confusion reigns when it comes to determining the appropriate contents of a business continuity management (BCM) policy document.  The internet has a plethora of policy examples in various shapes and sizes which can be very confusing to the uninitiated.  I tend to keep my BCM policy short.  But in some cases when my clients research the internet and find detailed policy examples, they feel short-changed by my less detailed document.  Let me justify my “less is more” approach…

When I first started in BCM a couple of decades ago, writing detailed BCM policy documents was the norm.  Maybe document thickness influenced billings.  Most people don’t realize that it can actually be harder to condense verbiage into something more succinct.  

If we keep in mind the core objective of BCM policy - that it is meant to communicate the guiding principles of BCM in the organization, we can get a feel for what a policy should and should not contain.  

Another reason to keep it succinct is because it is a senior management document.  Put in whatever gory details you need into other documents: BC Plan (BCP), BCM Manual, and the various annexures and appendices thereof.  But leave implementation details out of the policy.  

One of my clients, a multi-national from a consulting stint I did 10 years ago, was very reluctant to use the word “policy” anywhere.  They had a policy that any document with the word “policy” in its title (no pun intended) MUST be tabled at the board level – including any policy updates.

That’s one good justification for keeping the policy short and somewhat generally worded.  Senior management and directors don’t like to be bogged down with too much detail.  And if you change the details (and details will definitely change), it is not easy or desirable to burden management to re-read and re-sign.  On the other hand, the other afore-mentioned documents, like the BCP, can contain sufficient detail and can change as often as needed.  It may be enough for the Head of Department or Head of BCM to sign them off, without troubling top management.  

Let’s look at what the standards say….

ISO 22301:2012 defines policy very simply as containing  “the intentions and direction of an organization as formally expressed by its top management”.  

The BCI’s Good Practice Guidelines (2018) says: The business continuity policy provides the guiding principles around which the business continuity programme is designed and built. The policy acts as a statement to communicate the organization’s principles to interested parties. As its primary purpose is communication, it should be short, clear, precise and to the point.

In other words, the policy communicates principles, which implies it avoids the details.  It certainly does trigger details in the other BCP documents.  But the policy itself should shy away from implementation details.  It should define “what” needs to be done but not “the how”.  

That’s not to say the policy should never change.  There should be no hesitation to change it if the need arises.  But why set yourself up for frequent change by including implementation details in it that could just as easily be documented elsewhere.  

The policy is also a somewhat public document and that’s another reason for not providing details.  ISO 22301 says:  The Policy should be available to interested parties, as appropriate…. You don’t want to open up too much of your BCM approach to outsiders for obvious reasons!  Let them know you are doing it, to inspire their confidence in your resilience.  But no details please.