Recently, Andy Osborne, one of the Business Continuity Management industry’s most prolific writers, published a blog lamenting the common practice of writing BC Plans to please auditors – rather than to function as guides for Recovery.
Many Business Continuity Plans (BCP’s) are written to comply with Regulatory requirements (FFIEC, NERC, ISO22301, NFPA, etc.). Plans are often crammed full of information to meet audit requirements and fail to address the steps needed by Recovery Teams to take action.
I wholeheartedly agree with his premise. In fact, I’d go one step further:
Not only do many plans lack directions for action, many other Plans contain ‘procedures’ that are neither useful nor effective. The reasons behind those failures are often a function of who has written the Plan.
Time and time again I’ve worked with (generally large) organizations in which the BCM staff writes all the BCP’s – presumably with the assistance of the business process or function “owner” who will someday be charged with executing that BCP. Such arrangements are justified by the theory that “owners” don’t have the time or expertise to write them themselves.
That business model enables the conduct of large numbers of BIA’s, Plans and Exercises efficiently. But there are three ingredients in that model that lead toward the type of ‘compliant’ Plans Andy’s article complains about.
First, such plans must be based on a highly structured ‘template’. How else can an individual meet the goal of conducting annual BIA’s, Plan updates and exercises for 5, 10, 20 business units every year? That template should have two goals: meeting regulatory compliance or adherence to a standard (or even multiple standards), and providing the business unit with well-conceived actions to take in the event of an actual disruption.
Second, those BCM staff ‘planners’ often don’t have intimate experience necessary to fully understand how the underlying processes function on a day-to-day basis – making it difficult to understand what may be necessary to recovery those processes. They rely on the assistance of the process “owners”.
And that is the third flawed ingredient. Those ‘owners’ are required to cooperate, but have limited ‘skin in the game’, since it’s the writer, not the ‘owner’ who is responsible for the content of the Plan.
Even when such plans are passed by a higher-ranking functional manager for approval, that manager may also lack the intimate knowledge of the underlying process’ day-to-day functionality. Their ‘approval’ then constitutes little more than a rubber stamp of a plan they may not understand (and the more Plans they are required to approve, the greater that possibility).
So each of the players in this scenario operates in their comfort zone: the Planner relying on their knowledge of regulatory compliance, the owner relying on the guidance of the Planner (while spending as few hours of effort as possible), and the approver relying on their trust of the Planner and owner to have provided what is needed.
The result is a compliance-focused Plan, with little actionable instruction – the type of content needed to guide a Recovery Team through in Incident.
But, you may ask, shouldn’t the annual Exercise of the Plan highlight its shortcomings? It should. But too often it doesn’t, simply because the Planner is also the Exercise monitor, with a limited understanding of what the business process really requires.
And the scenario can worsen when the Planner is replaced by someone with even less knowledge of the business process’ day-to-day operations.
What’s the cure? First (as Andy Osborne suggests) separate the compliance “peripheral information” from the actionable part of the Plan. Second, spend more time focusing on what to do, rather than what to include. Third, assure planners who are not part of those everyday processes ask more probing questions to increase their understanding. A short ‘internship’ in the department or function wouldn’t hurt either.