all right. Now, the next phase of the plan is where we plan and design developed the plan. So we've done all the research. We have identified our strategies. Now we're gonna do the actual creation development off the plane itself.
And here's where we're gonna address the responsibility and we don't list those by names we listeners by roles within the organization.
What authority individuals have. Because, remember, in an environment that has a different you know, in a disaster based environment, we're gonna be working with the change staff, perhaps a reduced staff. We may have people coming in from the outside or from different departments, So we're gonna dress sort of the hierarchy and organizational structure.
What are prime work? He's our and the Morgan identify means of testing.
From there, we go on an implement the plan. We have identified what needs to be put into place so we put those entities into place. So whereas we decided, maybe we need to implement remote journaling
or we've decided that we need to have clustering instead of just rate or whatever that may be, we're gonna go ahead and implement those elements. And this is where
the formal plan is written and designed. We could sign off from senior management,
make sure the plan is kept in multiple locations. It should just be online and the facility. It shouldn't just be hard copy, though both of those should be true. He wanted Elektronik and a paper copy, and the plan should be distributed based on a need to know basis.
The entire plan in its you know when it's full entity
should only go to a couple of people you know should only get. There's key role players. Most people just get the portion of the plan that's relevant to them, and that part is usually things like, Here's how you evacuate the building. Here's where the accidents are here, those specific things that you need to know. We don't ever want to make the full
That's strictly need to know. That could be giving an attacker more insight than perhaps we then we would definitely want to have.
All right. So when it comes down to implementing the plan and actually writing it, we have to realize that there's an enterprise plan as a whole, but also each individual department will that have their own plan as well. Usually, their own disaster recovery plan that gets rolled up into the organisational plan is a hole.
It's just much easier unity to scale back the scope of each of these plans
and then combined them
now the three phases following a disaster or a disruption, notification, recovery and reconstitution. We talked about this earlier with the teams you know we talked about with notification.
We're gonna make sure that everybody knows we're in the disaster. Whether we do that through email, whether we use phone calls with the update, our Facebook page, whatever that may be. How do we know to fire people,
then, with recovery, recovery is all about getting the most critical. Service is back up and running, usually at an off site facility we call that fail over
reconstitution is about getting us back up to a state of permanence. We call that sail back
All right, Next piece
no matter how brilliant your plan, you should probably test.
So this is testing is very testable, and that's that's very true. I would definitely expect a good handful questions on types of tests here. I would also know the difference between a test and to drill
the test is all about verifying the plan for accuracy and completeness.
Test is about the plan.
Drills and exercises focus on employee response.
So we want to test the plan. We exercise and drill to improve employee response. A lot of times these terms used interchangeably. So five different types of tests the 1st 1 is a checklist test.
It's, Ah, Central. Just a checklist distributed to department heads and essentially, did I think of everything? Check, check, check.
Now the structured walk through. We take all those functional managers in their checklists, and we bring them together into a room and we'll sit around the table and we talked about.
What's important about this is it's called a structure walkthrough. But in my mind, I call it a structure. Talk through because it really you know, when you use the phrase walk through to me, I think about going through the motions.
A structured walk through is a table top test. It's a talk through. We take the checklist we completed in the first type of test,
and we bring everybody together and talk about him around the table. We don't actually go through the motions till we get to the simulation test and the simulation test. We actually go around and we verify that the elements we expect to be in place or there that we know how to turn off the H vac system
that the, you know, that we can access the switches for the water, vowels, whatever that may be.
Now we start actually get risky, though, with these next two types of tests. And that says drills over the top. That should actually say tests. Yeah, it was right on this slide. I've gotta correct that. That should say tests. But the last two types of tests parallel tests and full interruption tests, parallel tests.
Um, the idea is we have our permanent facility,
and then we have our offsite facility and we bring up a portion of operations at the offsite facility to see if we can process them. Now, that's risky, because if the offsite facility isn't configured properly, we could lose live data in life transactions. But even riskier is the full interruption test.
And that full interruption test says I'm gonna take my primary site down
and then bring up my off site and all transaction processing happens at the offsite facility that might work. Like, let's say, Friday afternoon at five, we bring down the original facility. Monday morning at nine. Operations resume at the offsite facility, so it's not always immediately a switch over.
But those are the types of tests.
Definitely make sure of them. Make sure you know the first tour paper based the third, the simulations where we go through the motions. The last two are the risky ones, parallel and full interruption.
After we conduct the test, what our job is is to figure out how to improve. That's the whole purpose of testing. How do I get better
now? We can look at what happened and what didn't happen. But our purpose is how do we get better?
And once we've tested our plan, we've got confidence in it. We put our plan into motion. We can't forget the importance of maintenance. Things change, and plans need to be reevaluated at least once for year, or is the result of a major change.
So we acquire another organization or we have a complete
re structuring of management or our infrastructure changes that would warrant going back and reviewing the plan, but at least once per year
make sure that the, um, the contributors to the plan make sure that we have that as part of their job rescript descriptions make sure that they're held accountable and that they're responsible for providing the elements. We audit the planet
when plans do get revised. The original copies and this is testable are retrieved and destroyed, and we want to make sure that nobody's referring to plan one point. Oh, when we're on three point of.