Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show notes: How To Create Business Continuity Plan Without Losing Your Mind!
Quick Take
On this episode of compliance unfiltered, we discuss the ins and outs of how to create a Business Continuity Plan without going complete nuts!
Learn to master your approach by fully understanding:
- What the hell is Business Continuity?
- Why are these plans so important to virtually all businesses?
- What types of things should an organization’s plan include?
- And once you have one in place… Where do you head from here?
All this and more on this week’s Compliance Unfiltered!
Remember to follow Compliance Unfiltered on Twitter!
Read Transcript
So let’s face it, managing compliance sucks. It’s complicated, it’s so hard to keep organized, and it requires a ton of expertise in order to survive the entire process. Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less.
Now, here’s your host, Todd Coshow, with Adam Goslin.
Well, welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow alongside the shepherd to your compliance flock, Mr. Adam Goslin. Adam, how the heck are you? What the flock? I’m doing great. I’m doing great. I’m just happy to be here. It’s way more fun than should be legally allowed, shall we say. 100% agree. But we do need to kind of keep it contiguous here. We kind of need to keep it moving. And to that end, we’re going to talk about something that really I think everybody can appreciate this time of year, especially as you’re trying to get your proverbial chising together, and that is how to create a business continuity plan without going completely berserk.
Well, let’s talk about what’s the struggle for folks to kind of generate their business continuity plan? I mean, obviously, there’s a lot on your plate, right? And you’re looking at all facets of the business. But when it comes down to actually laying it out, where’s the struggle? Yeah, well, the struggle for folks is that, we kind of covered this in the last podcast, talking about where do you need to fall? So a business continuity plan, for somebody that wants to go like completely nuts, right? Oh my God, I can keep going with this scenario, and that scenario. What if aliens land on the continent, and what happens if sunbursts are causing disruptions in the electrical grids, and specific instances? You could literally come up with this stuff all day long. And we talked a little bit about the notion of, if you go online and you pull down the handy dandy BCDR template, you know, hey, go fill in these five things and poof, you too can have a disaster recovery plan. It’s like, well, that’s useless. And yet, in the same sense, if you’re turning around and you’re doing, you know, and you’re creating every single possible scenario known to man, etc., this could be, no joke, a multi-year extravaganza, with hundreds to thousands of pages of just, yeah, sure, you thought through all of this stuff. However, by the time that you have finished your first pass at those things, which you would put into a category of more likely to happen, multiple years down the road, it’s an already outdated type of deal. There’s a middle ground to be struck as you go through this process without just losing your damn mind as you’re going through the process. Neither the half-ass approach, or the everything under the sun approach is going to kind of strike that middle ground. That’s something that I’ve always tried to do, I never want to half-ass it, but in the same sense, we don’t need to build the arc because it’s going to sprinkle tomorrow, you know. Let’s go ahead and make a reasonable stab at putting a good effort into the starting point that is, legitimately going to enable the organization to work, function, etc, without it just being absolutely out of your mind, and a stupid waste of time.
No, absolutely. And it can be very overwhelming for folks as they tow the first step of the mountain. So I guess that’s the perfect segue here. Like, where should we get started? Yeah. And that’s actually, that’s a good point. The problem that a lot of folks run into is, that when they first go in to start, honestly, it depends on where their mindset is as they walk in. Are they tending to the template, or are they tending to ad nauseam everything under the sun? Where you can get started, is first and foremost, just go in and look at the various business lines of the target organization. Let’s say if you’ve got an e-com platform, you’re provisioning several different services, you’ve got a call center, we have a self-hosting facility that we leverage, or a colo offerings. You’ve also got things like your corporate headquarters, any facilities which are involved, depending on the type of business, in any form of operations, business lines that come into play. First off, just get your arms around that. And it’s funny to say, but, you know, I can’t tell you the number of organizations where it’s like, you know, you got your world and, you know what you’re doing. Half the time, you don’t know what somebody else is doing, some other department, and some new service offering that they spun up and blah, blah, blah. So, it’s just a good approach to go in and just ask those questions anew, you know, let’s go gather up all the business lines and things that we do, etc. And then ,it’s going to take a little digging, believe it or not. The reality is, is that, you know, potential, disasters could be very different across any of those individual business lines. This helps you to get the major elements, you know, of the business together, so that we can identify those realms that require focus, as you continue to build out the business continuity plan.
What are other good ideas for reviewing the overall operations? So, operationally, going in and looking at the operational structure. So, you know, there are a couple of different things that will help with heading down that path. Certainly, depending on where the organization is in the grand scheme of things, but, you know, we either create or dust off, some documentation. Your network diagram is going to be helpful, having a physical and a logical up-to-date network diagram, which shows where any of your assets are, related to the various business lines that you’re analyzing. A data flow diagram, where it will show you what data is coming from where, who’s doing processing, where is it going, where is it getting stored, how is it moving, things along those lines. That’s another key element that will help a lot. Another arena is, a refreshed up-to-date list of any vendors or third parties that are involved in the organization. Identifying which of these folks is involved in which business lines, how do they provision services, what types of services are they providing, things along those lines. Having that list handy is going to be helpful. Now, we talked earlier, so I go through and I identify all my business lines, then I go and I gather up all this documentation, network data flows, vendors, third parties. Then as you’re starting to gather this stuff, start cross-checking, double-checking, blah, blah, blah, blah, blah. You’re looking at the dataflow diagram, you realize, I’ve got eight different service lines that I identified earlier, but I only see seven covered here, where’s the eighth type of deal? I know that this vendor says that they’re involved in blah, blah, blah, service line, but I’m not seeing them anywhere involved in the dataflow arena. Just cross-check, double-check, bounce these things against one another. You actually end up uncovering some things as you go through that. Certainly, after you go through all of the first pass of the documentation, your own mental comparison, etc. Then take a next step, which is talk to the people that are part of the workflows, part of those business lines. Get their input on the diagrams and vendor list. Is there stuff that’s incorrect? Is there stuff that’s missing? It may be that Mary, who was putting together the dataflow diagram, may not realize that there’s been a recent change in such and such a department, and that this vendor is now switched. Getting to the frontliners responsible for the business lines, those are going to help make sure that everything you’ve got is accurate, because it doesn’t make any sense to go generate a whole continuity plan based on facts that aren’t solid out of the gate. As you’re going through that process, you may also find that there’s functionality, or functions that they perform as they’re going through the business line delivery that aren’t captured in the dataflow diagrams or network diagrams, etc. It’s real good to have that interactive dialogue with the folks that are responsible for boots on the ground. You’d be shocked at some of the assumptions that people will make about how things work, how things function. It’s a lot better to get it straight from the horse’s mouth.
Always. Those assumptions are tough, right? I guess, what about the organization itself? Well, you know, going through and reviewing the organizational structure is an important element of this as well. The day-by-day operations, and the infrastructure are portions of the equation. But, you know, at the end of the day, the people are the most important factor for running the organization. So, basically look at the roles of the personnel within the organization. And, you know, reality is whether it’s, you know, kind of a front-liner or the CEO, everybody, they’re getting a paycheck for a reason, right? So, you know, they do play a role. Do you need to talk to everybody in the whole company? No. But, taking a look at that overall structure, start asking some sanity check questions as you’re going through it. What happens if so-and-so in this role, poof, is gone? I like to use the expression hit by the bus, and I use that a fair amount. What happens when Frank gets hit by the bus? What do you do then? etc. So, going through that list, looking for key points of failure, also having conversations with those individuals, asking them questions, doing some interviewing with them. Do you need to, whatever, let’s say you have 25 people in customer service or something, do you need to talk to every single person in customer service? Well, no. But, you know, do some sampling. I usually like to talk to somebody that has been there since the dawn of time, somebody that just started into that position. Okay. Motion alerts. It’s been a while since we’ve had that. Yes. I love it. Somehow, I don’t know. I must be living right, my motion alerts have been somewhat subdued lately. So I appreciate you giving everyone a little chuckle. So, looking at this, I was talking about somebody who’s been there since a dawn time, somebody that just got there, and then somebody that’s right around the middle. If I’ve got to go in and do sampling, that’s usually the way that I’ll approach it, I’ll go in and I’ll take one of each of those groups. For the ones that have been there since the dawn of time, it’s been a long time since the dawn of time, those are the people that they know where all the skeletons are buried. They know exactly how it used to work, how it’s been, what things they’ve tried, how it’s working today, the whole bet. So their input is interesting, but just as interesting as the people that just started into that arena, you get some real good insight into, what’s the training regimen like?
What type of training did you get when you onboarded? Was it any good? Things along those lines. So you learn things as you go through and start having those conversations. And usually, what I’ll do is I’ll have a conversation with the folks and they’ll say, I want you to kind of think about, who are the people in your mind’s eye that aren’t replaceable? Who are the people within your organization that there’d be a significant operational impact if they got hit by a bus type of thing. And gather that data, those data inputs, etc. Because that’ll give you pointers toward, where do I have these single points of failure in the organizational structure, kind of as I’m going through it, if that makes sense.
It really does. Now, where do you head from here though? So once you’ve kind of got, these compendium of various inputs, etc, it’s at this point in the game that now you’re ready to shift. Now you’re taking a reasonable shift into going through and looking at each of the elements, each of the procedures, processes, looking for any risks and how would we approach those risks? What type of shortcomings could we have with business continuity? So again, this could be, I don’t know, let’s say it’s a key vendor that’s connected through, that has like a SaaS service or something. What happens if their SaaS service goes down? Are you screwed? How quickly do you need them to be back up? If they aren’t, how quickly do you need a replacement? Is this so critical that we really need to have a hot-cold relationship for that vendor relationship? Do we need a hot-hot pair where we’ve got one that’s basically on live standby? Do we share the responsibility that that singular vendor takes today? And do we really want to split it between two, so either one of them could go pick up the slack if one had an issue? That’s just an example. But the risks and the response methodology is going to be different as you go down the list, and start thinking everything through and composing. Again, we don’t want the 100,000-page document type of thing with every single possible scenario. So instead, we’re going to start thinking, what I’d recommend is generate categories of disasters, levels of incidents, you know, some type of a description that would allow the users of the plan to be able to tell the difference between different categories, different levels. Maybe we’ve got, you know, level one is like, holy crap level. And the level four is, you know, go investigate or red flags, you know. Whatever works best for your organization, but get a gradient in place, create categories of things, you know, and as you start to pull together and really what it is, is it’s looking across, all of this stuff that we talked about gathering, right? Look across all of it, start to take your dart throws at the categories, at the levels, you know, things along those lines. And you may not get your kind of your framework perfect with the first shot. And especially as you start thinking things through, you know, etc, you may have to come back, make tweaks, make alterations, okay, this sounded great out of the gate, but I got a gaping hole right here that I got to plug, you know, I forgot about blah, you know, whatever it may be, you’re going to trip across stuff. So don’t get too worked up about the fact that you’ve got to go in. That framework is probably going to go through several iterations, you know, as you’re going down and you’re thinking it through. But, you know, as you go through, review all this stuff, balance and rebalance the framework that you’ve got, now you’ve got the ability to go in, and now you’ve got the ability to go in and kind of refine or hone, the basics of the plan. And that’s really where you kind of strike that middle ground of not just, half-assing it with some template you know, that you’d otherwise go be able to go pick up.
For sure. Parting shots and thoughts for the folks this week? well you know we’ve done a fair amount of talking it through. I think the obvious statement is, if everybody wasn’t able to read the tea leaves, is that you know the template, no. Hundreds and thousands of you know pages of everything known to man, no. You strike that middle ground, you don’t want to be in this hell of you know of iterating everything under the sun out. The important part about getting this framework together, is that you know if you find yourself getting down into the weeds, etc. That’s the moment that you need to say to yourself, you want to know what, I need to raise this up a level. I need to look at this generically. I need to see how what I just tripped across, applies to the framework and not get lost in the details. If you continue to exercise that restraint and keep yourself on that track for kind of a framework notion, then, you know, you’ll eventually end up with something which is far better than the answer these five questions template, and yet not have burned all the time for the multi-year, multi-thousand page extravaganza.
The other thing that’s important for folks to keep in mind is, when they get into creating these plans, it’s part of the reason why it’s real easy to go get dragged down the hole. It’s human nature for some people to want to get to responses, and direct instruction and blah and detail. And for some folks, it’s a struggle to kind of hit that middle ground. But the one thing I’ll say to those folks is this, don’t try to worry about making sure that this framework you’re putting together is a billion percent bulletproof on day one.
That’s usually what drives the issues which drag this stuff out. Instead, maybe for the first year, maybe two, is that you leverage the framework that you put together and use the lessons learned, right? As you’re exercising the plan with real world exercises, etc. This is something we talked about the last time too. Should we leverage it real world? Or be afraid to declare incidents and whatnot.
Absolutely, declare stuff. Don’t be afraid to use it. That’s why it’s there. So go leverage it. But part of each incident, or each business continuity event that you are dealing with every single time, take a moment, think about what went well, what went poorly, what do we need to do differently? How can we improve this? Was there things that were missing from our plan, etc? At least semi-annually for the first couple of years, but I prefer at least quarterly. Go through, do those kind of after event reviews, incorporate updates, changes, modifications, improvements, all that fun stuff, because that way, as your next incident pops up, guess what you’re going to find? There’s less and less stuff that you’re going to need to go and modify. And now you can take the forced quarterly pulse check, and you can extend that out to a twice a year pulse check, eventually extend that out to a once a year pulse check. But it really depends on the organization. If you find yourself continuing to deal with either incidents or events, needing to continually make changes to your plan, then keep up the cadence that you currently have. Scale it back when it starts to slow down. For different organizations, for different reasons, it happens faster or not quite as quickly. So gauge it based on your organization. But the one thing I would strongly caution folks not to do, do not get too overly aggressive about wanting to call this done and move on to the next shiny object. There’s a strong propensity for, yeah, yeah, no, we did this completely perfectly and there’s going to be no findings. Again, this isn’t about perfection. It’s about doing it appropriately. So don’t pull the trigger too fast to stop the regroup meetings, stop the continuous improvement. Keep it going until it makes sense to back it off.
And that right there, that’s the good stuff. Well, that’s all the time we have for this episode of Compliance Unfiltered. I’m Todd And I’m Todd Coshow. And I’m Adam Gosling. Hope we helped to get you fired up to make your compliance suck less.
