When Private Plans Go Public

Names have been changed to protect both the innocent and the guilty. I am looking at the business continuity plan for Company A. I am not working for Company A or any organization that would have Company A as a critical vendor – although Company A’s services most definitely fall into the “critical vendor” category. So why do I have the plan on my computer? Someone at Company A breached corporate security.

I’m Honest, But . . .

• The information on my notebook basically is Company A’s disaster response plan. In truth, it’s a pretty good plan.
• If I was working for an organization that had Company A as a critical vendor, I would be delighted to see the plan.
• If I was working in the agency that regulates Company A’s business, I would be delighted to see the plan.
• By the same token, if I was a disgruntled Company A employee, ex-employee, competitor, or just someone who wants to make a “statement” at Company A’s expense, the plan could be just the tool I need.
• DRJ’s pages have been the venue for plan security on several occasions, but none of those occasions addressed the “public plan,” a plan which meets client and regulator requirements but maintains the level of secrecy needed to protect the Company As of the world from prying eyes.
• We need to find a way to create this “public plan” as painlessly and economically as possible.

What Does a Planner Need to See

Obviously, a planner would like to see the entire plan, from proposal to final deliverable.

What better way to improve the planner’s effort than by looking at others’ work?

The question, however, is what does the planner need to see to develop a reasonable level of confidence that the organization for which the plan was developed meets all the requirements.

For absolutely critical vendors, a client or regulator might be justified in demanding to see who provides the vendor’s critical services and backup. It may be sufficient that the primary vendor simply state, “Multiple vendors provide the critical materials.” As to a back-up operation, I would want to know what organization stands ready to assure that the vendor will meet its service level agreements (SLAs) with my organization.

Critical Information

As a planner, I want to see what the vendor plan includes.

Is it limited to business functions? It is IT-specific? Or is it an enterprise plan? I need to be certain all the functions the vendor uses to provide the products I depend upon are protected.

I want to know who is sponsoring the plan. Was the plan created because a regulatory agency said the vendor had to have a plan? If so, what does the regulation require?

Some agencies only require a “feasible” plan. Demands to exercise and maintain the plan are absent.

Plans not exercised or maintained are not plans.

I want to know some critical dates. When was the plan created? When was it last updated?
If the plan was created more than a couple of years ago and the first update is still to be completed, the plan is not a plan.

If the plan was created more than a couple of years ago and there are annual updates, I’m a little happier … unless I know that the vendor has introduced changes in product, process, people, policies, etc.

All these things and others should trigger updates to the vendor plan.

I want to see when the plan was last exercised, and in general, what constituted the exercise.
Was it a desktop walk-through or did they “pull the switch?” Something in between?
While I don’t need specifics – some things may be confidential – I want to know “generically” how the exercise went, where there problems discovered, and are they being addressed?

In addition to the “generic” exercise report, I want to know something about the exercise methodology. Is it staged, and if so, what stage is it in now? What happens if there is a “P” change – product, process, people, policies, etc.

Equally critical, I want to know – again in generic terms – how the vendor intends to meet its SLAs with my organization. If it depends on vendors, I need to know how long it expects to continue this dependency. This will partially determine how much I want to know about the back up vendors.

It also may cause me to recommend contracting directly with alternate vendors and, if appropriate, increasing the on-hand supply of vendor products.

I want to see a generic overview of the vendor’s recovery plans. What are the priorities? Have all scenarios been considered? It makes no sense to replace damaged servers if there is no place to put them … or anyone to use the data “served up” by the machines.

I also would like to see a sample of the response pages.

Given my documentation background, I have this “thing” about clarity and comprehension. I want to see the KISS principle (Keep It Simple Stupid) in practice.

Interesting, But Not Necessary

From a planner’s point of view, having the “whole enchilada” is wonderful but hardly necessary.

The only reason I would want to see a contact list is to see when it was last updated. I would like to see an expurgated contact list, one listing response titles and perhaps “normal business” titles.

Having a list of responder titles gives me the opportunity to see if most functions are listed. I also want to know that each position has both “primary” and “alternate” staffing.

Having a list of “real” names has one benefit: it would allow me to guess with a certain amount of accuracy if responders will be over-extended.

Telephone numbers, addresses, and other contact information should be hidden. As with the vendor plan that kicked off this exercise, if the information falls into the wrong hands, anything can happen, from nuisance calls to physical attacks on personnel and their families.

While I want to see a response template, I don’t need to see actual response instructions. (Actually I do; it would let me – or an appropriate subject matter expert – see if a process or procedure is complete).

The business impact analysis is something in which a planner is interested for its educational value, but as a tool to rate a plan, of little use. Most of what I want to know will be covered in the plan overview, which I do want to read.

The risk avoidance and mitigation program – what is recommended, what will be implemented, and when – again is something that would be nice for educational purposes but something which could – and should it fall into the wrong hands – be detrimental to the vendor.

Non-disclosure agreements are worthless. They may have some legal weight, but by the time the matter is settled in court, enough damage may have been done to an organization that a massive revision of processes, procedures, policies, etc. is needed to restore confidentiality.

Two Documents, One Plan

It is possible to meet both private and public plan requirements with one document (set).
The tools needed are a good word processor that has a “hidden text” feature, an editor with a good eye, and a PDF generator. Free tools are fine, but pay the editor handsomely.

The trick is to create the complete plan – the controlled internal document – with the “sanitized” version in mind.

Once the plan is complete and approved, the editor goes over the document to “hide” any sensitive information. The information still remains in the word processor file and is available to anyone who takes the time to “unhide” it.

The PDF generate takes a “picture” of the visible word processor file. The hidden content is ignored.

The sanitized plan is available to share as a data file or printed out as hard copy.

With a little thought, organizations cannot only advertise that they have plans in place, they can confidently provide evidence to support the claim without sacrificing security.

John Glenn, MBCI, has been helping organizations of all types avoid or mitigate risks to their operations since 1994. Comments about this article. or others at http:/johnglenncrp.0catch.com/, may be sent to JGlennCRP@yahoo.com.