Understanding Business Continuity Management (BCM) in CISSP Domain 7
To Download the FREE PDF of MindMaps
Your information will remain 100% private. Unsubscribe with 1 click.
Hey, I’m Rob Witcher, and I’m here to help YOU pass the CISSP exam. We are going to go through a review of the major business continuity management topics in Domain 7, to understand how they interrelate, and to guide your studies and help you pass the CISSP exam.
This is the sixth of six videos for domain 7. I have included links to the other MindMap videos in the description below.
Business Continuity Management (BCM)
Focuses on critical and essential functions of business
Goals of BCM
There are 3 major goals of business continuity management, and you need to remember them in this order.
1. Safety of people
Number 1 most important goal is safety of people. People are the most valuable asset to an organization, and without people there will be no organization.
2. Minimize damage
Number 2 is to attempt to minimize the impact, minimize the damage caused by the disaster.
3. Survival of business
So that 3, we can help to ensure the survival of the business.
Business Impact Assessment
The first major process that we perform in Business Continuity Management is the Business Impact Assessment.
Identify Critical Processes & Systems
If it through the BIA that we identify the most critical business processes and systems by consulting stakeholders from across the organization.
Measurements of Time
The major output of the BIA process is four different measurements of time that have been approved by the process or system owner. The owner must approve these numbers because ultimately the owner must pay for the costs associated with achieving these numbers. And let me re-emphasize each of these numbers is a measurement of TIME: seconds, minutes, hours, days…
The recovery point objective, the RPO, is a measurement of how much data an organization is willing to lose as a result of a disaster. So, if the server explodes, what is the maximum tolerable data loss as a measurement of time. 5 seconds worth of data or 10 minutes or 3 hours or 2 days.
The Recovery Time Objective, the RTO, is a measurement of the maximum tolerable time to recover systems to a defined service level. Typically, this means how long it takes to bring backup systems online
The Work Recovery Time, the WRT, is the Maximum tolerable amount of time to verify system and/or data integrity as part of returning systems to normal operations
And the Maximum Tolerable Downtime, the MTD, also sometimes referred to as the Maximum Allowable Downtime, MAD, is the Maximum time a critical process or system can be disrupted before there are unacceptable consequences to the business. The MTD is always going to be greater than or equal to RTO + WRT.
And here is a diagram that summarizes these numbers. This visual helps me remember how these numbers fit together.
Owner approval of #s and associated costs
And to emphasize this point: it is the owner of a process or system that must approve these RPO, RTO, WRT & MTD numbers, because the owner has to pay for the recovery strategies that will allow these numbers to be achieved.
Types of Plans
Now let’s talk about the two major types of plans that these numbers drive the creation of:
Business Continuity Plan (BCP)
Business Continuity Plans, BCPs, focus on critical business processes. For example, paying employees is typically considered to be a critical business process, so in the event of a disaster, like our automated payroll system blowing up, the BCP plan would focus on how to continue the business process of paying employees. BCP plans essentially focus on the survival of the business.
Disaster Recovery Plan (DRP)
Disaster Recovery Plans, DRPs focus on the recovery of critical technology, infrastructure and systems. So, in the example of the payroll system exploding, while the BCP is focused on keeping the payroll business process running, the DRP would be focused on recovering the actual payroll system.
It is incredibly important that BCP and DRP plans are tested periodically. There is little likelihood that the plans will work effectively in a real disaster if they haven’t been tested and refined based on the results of testing. Tests are typically done in order, starting with the first simplest test, refining based on that test, and then moving on to the next more comprehensive test, refining, and moving on up incrementally through all the tests like this.
Read-through / Checklist
The first simplest test that can be done is a read-through or checklist. This is where the author of the plan reads through it to make sure they haven’t missed anything. They essentially go through a checklist, a plan should include call tree names, alternate contact info, etc. etc. Is all that information correctly written down in the plan.
A simulation is again an entirely paper-based exercise, where you have stakeholders sitting around a table with copies of the plan in front of them again. The difference is that you invent a scenario, like a virus outbreak, or an earthquake at a location and now everyone at the table must try and follow the plan as though the disaster were occurring. You then periodically throw in some updates or twists: this data center just went offline, CNN is on line 3, to see how well the plan works in the scenario.
A parallel test is the first time that any systems are actually touched by the test. Specifically, only backup systems, and NOT production systems. This is again a scenario-based test, some scenario is invented, and people have to try to react to the scenario using the plan and trying to do things like bring backup systems online.
Full-interruption / Full-scale
The final and most important type of test that we perform is a Full-interruption or Full-scale test. This is literally where we cause a disaster. If you really want to know if your backup power system is going to work when the power is cut, the best way to test this is to…. Cut the power. Full-scale testing should only be performed after every other test has been performed successfully and you have management’s approval. Remember CYA
How do we determine the order in which we restore business processes and systems?
Most critical systems first
Rather obviously we restore the most critical processes and systems... first. This is another important outcome of the BIA process. Part of the BIA process is to get a bunch of business and system owners around a table to argue and determine which processes and system are truly the most critical and in what order they should be restored.
We also need to create what are known as dependency charts. We usually can’t just bring up a system in isolation, we must consider what dependencies the system has and bring those dependencies up in the right order. Dependency charts help us map this all out.
And that is an overview of Business Continuity Management within Domain 7, covering the most critical concepts to know for the exam.
If you found this video helpful you can hit the thumbs up button and if you want to be notified when we release additional videos in this MindMap series, then please subscribe and hit the bell icon to get notifications.
I will provide links to the other MindMap videos in the description below.
Thanks very much for watching! And all the best in your studies!