How do you stand up a successful business continuity program from scratch?
In this episode of the Managing Uncertainty Podcast, Bryghtpath Principal & Chief Executive Bryan Strawser walks through the process we use at Bryghtpath using the example of an organization without a current business continuity program. Topics discussed include business continuity policies, program charters, executive sponsors, steering committees, the initial Business Impact Analysis, business continuity planning, and more.
Related Episodes & Blog Posts
- Blog Post: Your Reputation Command Center: The need for a rapid response process
- Blog Post: 3 Key Metrics for Business Continuity Program Success
- Episode # 121: Metrics for Success in your Business Continuity Program
- Episode #132: 7 Business Continuity Exercise Scenarios
- Episode #139: 2022 Trends in Business Continuity and Crisis Management
Episode Transcript
Hello, and Welcome to episode 144 of the Managing Uncertainty Podcast. This is Bryan Strawser, Principal and Chief Executive here at Bryghtpath. And in this week’s episode, we’re talking about how to stand up a successful business continuity program or business continuity and crisis management program, if you want to think of it in that way.
What I want to do is take you through our thought process about standing up a business continuity program. This might be a little more elementary than what some of our podcasts have gotten into. We’re going to take this using the example of an organization that simply doesn’t have the business continuity program, but knows that they’re ready for something that helps ensure the continuity of operations for their organization. And we’re going to take you through our thoughts about understanding the lay of the land and then how to establish those year one capabilities. And then what that looks like coming out of that down the road.
From our standpoint here at Bryghtpath, we believe that organizations of most size should have a business continuity program. And there’s a lot of different ways to approach this, but at a macro level, from a headquarters standpoint, organizations should have a business continuity program where management through some centralized program or resource has identified the critical capabilities of the organization. They understand the things that have to keep happening for its long term survival.
And then they create business continuity plans for those capabilities that allow for the recovery of those teams and the important work that they do when the disruption to your workplace, your workforce, the technologies that you depend upon, and your vendors, suppliers, third party service providers. To achieve its goals, we believe that business continuity needs to be closely aligned to IT’s disaster recovery or high availability approach that owns the resiliency of your critical information, technology systems, and infrastructure. And you truly cannot have one without the other because almost every job in today’s world has such a dependency on technology.
So where do we start? Well, we always start with trying to understand what does an organization really need? What is your industry and what are the strategic objectives of your organization and where does business continuity really ladder into that? In other words, it’s the value proposition of understanding why are you doing business continuity and how does it support the strategic objectives, the mission of your organization? Why does that really matter?
And you have to start there to really have the business buy in. Now, you may be coming at this from the standpoint that you’re in an industry that is regulated. So in the United States, that means you’re in healthcare or a healthcare delivery or insurance, or you’re in a financial services industry. You’re in a credit card or pharmaceutical organization, or you’re in certain types of manufacturing that are highly regulated. And you have a compliance reason for your business continuity program. That’s a good reason. The compliance challenges facing the financial services industry, for example, related to continuity and disaster recovery are quite significant. And these organizations have large continuity, disaster recovery teams, large crisis management and security teams. And they need that, because of the regulatory burden that they need to meet.
But a lot of companies particularly here in the United States are in industries that are simply not regulated from this standpoint. So aligning your program to the needs of your organization and explaining how your program would support the strategic objectives of your company become really important. So for me, that’s where things start, how do we make that strategic alignment on how business continuity supports the strategic initiatives and mission to your organization? What’s the value? And then it’s important to have a champion. You need a member of the C-suite or someone who has the ear of a key member of your executive team to really be your champion, your executive sponsor, who wants to help you work through this program and believes in this and will push it with their program.
And from there, we really think about starting to lay out the elements of your program. And as we do so, we want to start with the things that are basic, that get you to that year one capability. And then you can get fancier with this process over time, but you don’t want to go in and try to layer in a massive compliance driven continuity program out of the gate, or trying to force those changes on your organization are just going to make it really challenging.
As you think about your program, we really try to position business continuity around this is about keeping the critical business functions and capabilities of your organization running and recovering them quickly in the face of a disruption. And a lot of companies here will get hung up on the hundreds of ways in which your organization can be disrupted. And we can get there, but we want to start with, look, I want to address the consequences of that disruption, because that’s what’s going to in impact you and you can call it different things, but there’s four of them that impact your ability to do the work.
And that is an impact to your workforce. That can be the COVID-19 pandemic we’ve all been through where people could be too sick to do the work. It could be an impact to the place where the work is done, impact to a workplace, to a facility. So you’ve had a facility outage now because of a fire. So that’s a continuity challenge to work through. You can have impact to a third party service provider or a supplier or a vendor, depending upon what the business is that you’re engaged in. And that has an impact on your team’s ability to do the work. You might be missing critical parts. You might be missing the service supplied by that third party. You might be missing the software that third party provides.
And then lastly, there’s impact to your critical technologies, impact to the technology systems and infrastructure that your teams rely upon to do the work. And that can be a production technology outage. It can be an outage to a cloud-based SaaS tool that you use, like Salesforce or Office 365 or Slack. And so we focus on the consequences of that disruption. We center our program around understanding and capturing those dependencies and impacts, and then planning around how do we work around that? So we start with, what does a organization need? How do we ladder up the strategy? We focus on the consequences of a disruption. We want a champion and executive sponsor, and then we start to lay out the program. And we think about this in a couple ways. First, there are some program elements that you want to put into place. It starts with policy. What is your organization’s policy for business continuity? That is where you connect to your strategy. You define the scope of your program and you define the governance of your program and your high level roles and responsibilities.
So here you’re outlining the role of that executive sponsor. You should establish a steering committee or some type of governance body, and then you’re going to meet with them regularly to keep them informed. But you’re also going to leverage their capability as leaders across the organization to get your program done. And then we always encourage you to ground your program in an industry standard. We usually recommend the ISO 22301 standard. This does not mean that you need to implement every single clause of everything that’s in the standard, but you should use that as a reference to ground your program activities so that you can point back to it and say this is our guiding standard that we’re following with these modifications, and then document those things.
From there, we want to start thinking about the elements of your program. We always lay out that we want to start with an assessment across the organization, a criticality and business impact analysis or a BIA. And what we’re trying to understand here is what are the functions and how do they ladder up in the organization that are truly critical? How long can those functions be disrupted before that impact is unacceptable to your core business operations? And then what are their dependencies? What are their dependencies on applications or technology, on vendors or third party service providers, on other business teams, on facilities and on the workforce? What’s their minimum staffing and what are those critical positions? And which of those positions are hard to fill? Maybe there’s a unique skillset that only sits in one person and it’s not documented. There’s no SOPs. There’s no procedures and she’s going to retire in five years or less. So we capture that dependency.
And then you want to validate that BIA, that assessment with your leaders. As you think about how to do the BIA, it’s also important to talk with your IT team. In fact, your IT team should be part of your steering committee, your CIO, or another leader, but you want to talk with information technology about what are their needs in capturing this critical application data as you do your BIAs, because this might be the first time they have a good analysis of these are the critical applications in the organization. Here’s who uses them. Here’s when they need them back. And in doing so, you probably will identify some gaps where your business teams need applications back, much more quickly than IT has planned for or much more quickly than they’ve contracted with a vendor for SaaS tools for that tool to be back online.
Then we make plans and here we’re building business continuity plans. Again, don’t overcomplicate this. We want to build business continuity plans that address the consequences of those disruptions. How do we work around an outage, if we can work around. What do we do if we lose our workplace? What do we do if the workforce is impacted? Can we go to alumni in the organization to do the work? Can we go to a third party staffing firm? Do we have to post the position and recover it that way? Do we have contractors or contracting firms that we can draw upon? Do we have an outside partner we can pull in? What do we do if the technologies we use are impacted? Can we work around a Salesforce outage? If email is down, can we use Microsoft Teams or Slack for communication? Can we call or text people? How will we manage in those situations? And so you start to play out those disruptions around those technologies and such that you’ve captured in your BIA.
And then how do you activate your plan? And those are the steps that we want to build into your business continuity plan. You want a consistent template, a consistent process across the organization. Then you want to train your teams to those plans. And then we recommend conducting a facilitated tabletop of those plans. Your goal here is to build muscle memory, that they get used to using those plans. And then we go back and update those plans based on the lessons learned from those exercises. You want your business teams to own this process. Your role as the program manager, program sponsor is to govern and oversee this process, not to write the plans, not to do this from a step by step standpoint.
The next thing to think through is just where does crisis management fit into all of this? Is it part of the continuity program? Is it a stand alone program of its own, in which case you’re going to want to work closely together? Or is it something else entirely? But the important thing is when there’s a disruption, how do you use your business continuity plans as a part of your crisis management process when it’s appropriate to do so? When that business team is disrupted and that business team is in danger of exceeding their recovery time objective. So how do you pull those two together.
Beyond that you have, as you’ve gathered this data, you’re going to find out that your BIA data is like gold. That application data, your IT team wants to understand that. It might be the first time they’ve seen it. Your vendor data of vendor dependencies and how long the business teams can live without those vendor services will be incredible information for your vendor management, your procurement teams, or whatever you might call that in your organization.
All of this also gives you the ability to start to weave a really interesting story about business continuity, about what’s most important in your organization to recover first and why. And how do you bring in new teams as your company expands? How do you expand the program to support those new teams, new individuals, new lines of business that are brought into your organization? What is the impact of an outage for example? A simple example from one of our clients that is a technology firm that makes a set of technology products, but one of their dependencies is on a piece of software that a lot of you will know, and that’s Salesforce. And their internal IT team’s thought on Salesforce is that, “Well, hey, Salesforce is used by our sales organization. That’s what it is, that’s what it does.”
And when Salesforce had an outage a year or so ago, over an internal DNS issue that took Salesforce down for several hours, their internal IT teams take on this was, well, just the sales teams impacted, and we don’t need to really worry too much about that. But their continuity program manager was able to say, well, no, that’s not true. Our BIA data shows us that Salesforce is used by all of these other parts of the organization, including their client support center, including other teams that used it for ticketing and service support in similar areas, enhancement requests and more, and it really raised the awareness of the team about how important this was, that they needed to get this application back and how they needed to communicate more broadly. They would never have known that if they had not done a full BIA and had not built that into their business continuity plans.
That takes you to really the first year of your business continuity program. That storytelling that we talked about should be something that you’re talking regularly to your steering community about. But it’s also information that you should share with your executive team. And hopefully you’re board and the audit or risk committee of your board, depending upon how you’re set up.
In your following years, you want to essentially rinse, wash, and repeat this cycle, right? But now you have those basic program elements are done. They’re out of the way. You don’t have to rebuild your policy, although you should review it. You don’t need to recreate all of your program elements. You have them. Now you’re updating your programmatic documentation. And then you’re conducting that annual life cycle again. You’re going to review the BIA. You’re going to update your plans or create new plans. You’re going to train the teams. You’re going to do tabletops again. You’re going to learn from those. You’re going to update your plans and you’re going to continue that cycle of progress. And that really takes you through the year over year.
On top of that, you’re going to continue to enhance your program. You’re going to keep looking for gaps that you need to close and drive to a close through your steering committee. For example, you’re probably going to find that you have big gaps between your vendor SLAs, and when your business teams tell you they need vendors to be back up and running. You’re probably also going to find gaps between your technology team’s ability to recover an application and when your business teams are saying they need that back. Those are great gaps to highlight to your steering committee and then undertake efforts to reduce and eliminate those gaps year over year.
And it takes a long time. But as you continue to narrow those down, the more resilient your organization becomes. I can’t emphasize enough the need to have a strong executive sponsor, a champion for your program to leverage your steering committee. Not to think about them as a body, just for oversight and that you have to report back to, but think about how putting information in front of them can help you gain resources and close gaps that you identify in your program and use them, leverage them to help tell your story across the organization.
Now, I’ve probably made this sound really easy. We know that it’s not, and that this takes a lot of time and a lot of investment, a lot of banging your head against the wall as you go along. But these are some things we’ve learned, I’ve learned over 20 some years in this space trying to build… Building, I should say, successful programs and helping our clients do the same. Hopefully, you were able to gain some insight from that, a little bit of knowledge dump there. That’s it for this edition of the Managing Uncertainty Podcast. I’ll be back next week with another new episode. Be well.
