Introduction to Continuity Plans
Introduction to the Business Continuity Plan module
The business continuity plans module helps you define your continuity plans. For example, if a continuity plan is related to switching the SMTP provider (see screenshot below), you will define the plan title, who is involved in the plan, etc.
In addition, a plan must contain tasks to be executed. In Eramba, every continuity plan must contain tasks that describe who must do what, when, where and how. Following the example described before you can see in the screenshot below that this plan contains two tasks.
Once you define your continuity plans, their tasks and who is related to them you can also define how frequently you would like to audit these plans. As you can see in the example we are using this plan has gone through two audits, one of them completed and the other one is missing.
While this module can be used as a standalone module, is oftentimes best to initiate the implementation by performing a Risk exercise, documenting your business-related risks on the Business Risk Module (see Risk documentation for details) and associating Continuity Plans as mitigation to these Risks.
The diagram below shows all modules involved in this exercise and how they relate to one with another.
Accountability is extremely important and for that reason, every plan and task will have multiple roles associated to departments in your organisation. In the case of business plans you have three key roles:
- Owner: the GRC department that has an interest in this plan to be documented and tested
- Sponsor: whoever is affected by this plan
- Launch Responsible: the department in charge of deciding if the plan should be initiated or not
At the task level, you have a task-responsible department associated with every task.
These roles can be renamed and of course, you can add more roles as needed by simply using Customisation capabilities built into eramba.
Continuity plans should be tested, for that reason on each plan you create you can optionally define how often they must be tested, how and by whom. Defining these audits dates will create audit records that will be used by auditors to test plans.
Your audit records include the details on how the plan should have bene tested, when it was tested, the result and all evidence and audit trails will be documented as comments and attachments on each audit record.
eramba can trigger a multitude of notifications based on common scenarios (such as a week before the audit, when the audit is closed, etc) or based on your custom scenarios (when a plan mitigates a risk classified as high). See the notification documentation for details on how to define them.
You can create custom reports using our report builder to describe plans in more graphical terms. Your reports can include tables, filters, charts, etc.
