Business Continuity Plans

Define continuity plans and regularly test them

  • Episodes5
  • Duration9m 3s
  • LanguagesEN
Episode 3

Identifying Continuity Plans

Our preferred method for Plans identification

Introduction

In this episode, we provide ideas on how existing Continuity Plans in the organisation can be identified and documented in eramba. Is important to remark that this identification process focuses on existing continuity plans, not in plans that should exist.

Business Risk

Continuity Plans cost money and therefore there is no point in having endless plans for all possible Risk scenarios in the organisation, as discussed in the Risk documentation your teams should have identified Risks (in this case those focused on Continuity) and from those that prove a serious threat identify what existing continuity plans exist in the organisation.

That Risk exercise will provide you with the risk scenario and the department affected, this department will become the sponsor of the Continuity Plan. Is typically in their interest to have and pay for a Continuity Plan.

Requirement

Is not possible to document Continuity Plans in eramba unless the two (ideally three) conditions shown in the diagram below exist.

  • Problem: a risk should be identified in the Business Risk module. This is optional.
  • Team: a team that owns the plan and is able to execute it, this is hardly ever the GRC team
  • Runs: the continuity plan must be in production, it might not work great, but it must be there.

Is very important to avoid creating Continuity Plans that have never been tested, discussed, etc. 

Identification

Once a team and a plan have been identified (ideally a driving problem as well) your teams should interview the department (sometimes a plan might be executed by multiple departments) that runs the plan to discuss the key attributes of a BCP in eramba:

  • Name
  • Who will sponsor the plan
  • When and who approves the plan to be launched if needed

With these basic components, you can now discuss with the sponsor and the launch initator role what the plan is:

  • who (department)
  • does what
  • when
  • where
  • how

A plan in eramba requires one or more tasks composed of the attributes mentioned above. As the tasks are defined the plan takes shape. Once the tasks have been defined all stakeholders need to agree on:

  • How often the tasks should be tested
  • What is the testing methodology
  • What is the success criteria

With all these elements you will be able to create a BCP in eramba.