Strengthening Healthcare Resilience Through Business Continuity & Impact Analysis

Those are some of the areas we want everyone to understand why it's important and why is that become such a topic in the healthcare arena. Also, just importantly as it relates specifically to a business impact analysis, how does it help prioritize risk for your organization? So more than just doing it for a business continuity plan, understanding your business impact analysis helps you understand what the KPIs, the key process indicators are across your healthcare organization, and that's important from mitigating risks to ranking risk, right? The more you understand KPIs throughout your organization, the better you're going to be able to help manage risk and the better you're going to help understand where everyone in your organization is. So it's obviously important for a business continuity plan, but it can help you manage across your industry from different scenarios that's not just important to the BCP, and you'll also be able to understand how your organization's continuity plan measures up against other BCP frameworks. Where do you stand currently compared to other healthcare organizations and other organizations out there with the maturity of your current business continuity plan and what do you need to do to ultimately get to what goal you have to mitigate risk for potential future outages, and a, to make sure you can keep your patient care and you can keep your organization running?

Paul Douglas:Let's ready ourselves for as many acronyms as we can consume together over the next 50 minutes. I introduced BCM, so business continuity management is often a way we think about the key areas of your business continuity needs, and a little bit about myself before I start going into the first slide of acronyms that we will cover together over the next 50 minutes. So I've had the great fortune to help organizations across different industries and development of their business continuity capabilities, their disaster recovery capabilities from an IT resiliency standpoint, and it is very true that the business continuity needs within the healthcare sector are complex. There are so many departments where we're already, it's a high availability environment, so downtime within some of our clinical care settings can be very catastrophic depending on what that setting is and what may be the type of operations that are occurring within that setting.

Absolutely, although I have worked with a number of industries on their business continuity needs, the needs within the healthcare space are unique, and that's important for us to think about. There's also lessons we can learn from other sectors. So when we think about this topic, we're bringing all those experiences together and business continuity management is a nice overarching way to think about this. This is more than just an IT topic. Your business continuity plan is very business operationally driven. Your disaster recovery plan, which is built upon the needs of that BCP, your DR plan is more IT centric. So think about your DR plan is the IT side of the business continuity plan, but then there's a third lane, which is very important for our industry is the crisis management piece. Not all disasters are created equally. We'll talk about a variety of disasters throughout this presentation. Some are adversarial. Think of your adversarial disaster as a large scale cyber attack. Could be something like a bomb threat, an on-campus shooter situation.

These are far more than just disasters. These are crises that require us to activate a representative plan to be able to properly respond. Then you have some of your non-ad adversarial attacks. Think of that as your environmental, a weather situation. We will often compare the type of a disaster event. You'll see kind of comparing that of a hurricane to a tornado, and what I mean by that is a hurricane is very strong or could be very strong, very impactful, but it's slow moving. You have as many as five days, seven days notice to ready yourself. In the case of a tornado, you can have very limited time. So it's that concept of velocity and veracity and that's you want your business continuity plan, your disaster recovery plan, and even your crisis management plan to work together in harmony to be able to respond to the many adversarial and non-adversarial disaster events that could occur through your organization.

So we'll go into each of these throughout the presentation. I'll also say for the various folks on the line, we work on each of these with various stakeholders. We work with the chief operating officers, we work with the CIOs and the CISOs From a DR standpoint, we work with internal audit. This is a great place where internal audit can be a champion in helping broker some of the conversations because a lot of these are risk-based decisions we're having to make. We do not have, or I think we don't reply in the chat if you do, but we do not have enough resources to have a perfect plan for every scenario. So what that means is we need to prioritize our resources. Internal audit is a great department to help with that because internal audit is going to come at it from that risk lens and help advise on where we should really be prioritizing. So for your organization, think about when you look at this BCM, this business continuity management structure, do you have that business continuity plan that feeds into your DR plan? And do you have the separate crisis management layered on top to manage the variety of scenarios that we're going to have to potentially address one day?

Cody Loup:All right, so you've heard me and Paul both hit on why a business continuity plan is so important for healthcare, but why is that, right? I mean, I think some of these are obvious, but I think others will go into a little more detail here on exactly what that means. The first and the most obvious on why it's so important is patient safety depends on uninterrupted care. We can't close a healthcare center. We can't close certain rehab centers just because the weather's bad. We can't close and say, well, our systems are down, right? We're not running a restaurant where that's possible to close operations. There's a water leak. We can't do that in the healthcare setting. We can't do that to our patients just from a fiduciary standpoint, but there's also the regulatory standpoint that can't happen. We have to have uninterrupted care. I know some people are probably trying to think of what areas do we have that?

Well think about it when the power goes out, right? That's a very simple scenario where uninterrupted patient care is taken care of. Your hospital is going to have generator power, and then for the machines within the room, you're going to see those red outlets. If you've ever done site visits of your hospital beds, those red outlets are for when you're on the generator power, right? It's not going to go out. So that's a type of business continuity plan right there. You may not know it. You may not have called it a business continuity plan, but that's exactly what that is. It's an example that you've taken at your hospital to make sure there will not be uninterrupted care if a power goes out. There's also the regulatory and accreditation requirements. I've yet to see this as a good example that will give an answer to CMS or Joint Commission if they write you up.

Well, our normal operations were down. They're not going to take that as any excuse obviously. So just besides the patient care, which is ultimately what we care about the most, you want to make sure you're up to regulatory standards and regulatory standards are going to be that you deliver care towards their goals regardless of if your normal operations are operating. So that's another important factor. One of the biggest ones here is going to be your reputational risks. I've seen through my years of experience where they've had medication management issues. Let's say if your medication has to be kept at a certain temperature and the temperature falls outside of that range for a certain period of time, well, that medication is no longer applicable. It's basically considered expired If you don't have proper situations to monitor that, for you to know that the temperature range was out or for you to go correct that short enough time, there's a potential.

You could give patients medication and you're going to have to let them know on the backend, I'm sorry, but what you took, whether it be a vaccine or something preventative was really not giving you the protection because the standard of care was not delivered. You deliver that news to enough patients. You're going to have a situation where I'm pretty sure they're going to get your local news on the line, hopefully not your local attorneys, but if not, and that's going to be a huge reputational hit to your organization because you didn't have a plan in place when operations were disrupted to make sure that that was corrected or at least known by someone in your organization to be able to monitor that, to be able to let them know so they could go get a separate storage situation. And there's also financial risk, obviously, right?

The patient care is the most important part, but something I was told early on in my healthcare career, there is no mission without a margin. And so that's true, right? The financial services part is huge, and so when we're down and we can't take in revenue that affects the patient care in a way, we have to have the financial capability in order for us to deliver our care. So anytime you're down, and even if you do have some type of continuity plan, but if it's slowing down your operations, that is lost money, which is obviously going to be a negative effect. Your organization. Another thing that's very unique for healthcare, right? Everyone has third party dependencies, but it's amazing how many third party vendors as well as different IT environments we have in the healthcare sector. Not only do we have a third party probably managing our electronic medical records, we have them monitoring our medical devices, whether it be General Electric or others.

We have M Stryker with the instruments we're actually putting into our patients. We have different people with our beds in our hospital, so it's on and on and on who we have that we're relying on for third party dependencies, which is kind of unique. We'll touch on this later, but it's not just your third party dependencies, which are massive to make sure you have an awareness of it's your fourth party dependencies. What that means is who do your vendors depend on, right? If you have a contract with Epic, it's obviously important if Epic is down, but Epic relies on other vendors and it's important that we know who they rely on because if they're down, then that interrupts our standard of operations. And so there's just so much to try to digest for each operational area. We need to be able to define this overall so we know exactly how much we're relying on others to keep our normal operations up. And so that's the reasons why we say this is so important for us in healthcare. It's just because we have so much going on in different silos that sometimes we don't see it from an overall big picture and we don't really understand the risk we have because of all these different areas we have within our organization. And saying that that'll bring us to our first polling question, why is business continuity especially important in healthcare organizations? I'll give everyone about a minute to respond,

And after everyone responds here, if anyone wants to, in the q and a chat put who has dealt with the business continuity plan before, just so we know who we're speaking to, if you've looked at it in your area, if you've helped create one, if you've at least seen it for your organization, if it's on a website, just so we have an idea on I guess some of the experience we have within the group with the BCP. All right. It looks like we have about 90% of respondees, and so yes, it looks like everyone for the most part got this correct. Why is it important for healthcare organizations? The most important part is patient safety, depends on uninterrupted operations.

Paul Douglas:All right, thank you to our BCP PM that jumped into the chat. Welcome aboard. I hope we don't let you down. What an area to be a pm. You talk about PMs, the lifestyle of herding of the cats. Oh my gosh. Project managing the BCP needs across a provider organization. You must have a really exciting job. So good to have you on the chat, thanks to others dropping in here. Alright, well, we're going to talk about two passion slides that I have within this presentation and it revolves around the BIA. As I mentioned, I've had the great opportunity to support the drafting of BCP plans and the IT DRP capabilities of organizations. The BIA is the foundation of that. So if you can think about the business continuity plan and the disaster recovery plan as kind of the house that you're building, you cannot build that house on a foundation other than the business impact analysis. It is so critical.

Conversely, if we do not perform a thorough business impact analysis, our plans are really based upon guesswork and our reliance upon what we think the needs are. A BIA done well greatly challenges what our continuity plans should look like and then consequently what those disaster recovery plans should require or what they're supporting. So let's talk about that a little bit more depth. The business impact analysis you were identifying, you are putting the paper or in Excel or within a tool you were formally documenting. What are those critical processes that we want to have contingency plans for? When you inventory those critical processes, you are doing a lot of what Cody was mentioning. You're identifying what are those third party dependencies, fourth party if you have knowledge or the end party risk, if you have knowledge of what those may be. At a minimum, what is the third party dependency? What are the system dependencies? Here's an aha moment. What are the data stores that we rely upon that can be complex depending on the environment? In some environments, we're operating off of external hard drives. Some environments we have, we're copying the data down, putting it somewhere because that's where our users are really interacting with the information. We need to have resiliency across those, what I would call disparate data stores. And within the healthcare environment, we absolutely have disparate data all across our organization.

So the BIA is intended to find those places, to find those systems. And it's not just the core ERP, it's not just the core EHR that we're utilizing. It's all those connected systems, those separate data stores that exist across our environments that we will need at some point. What is that point? That's where introduce more acronyms. The MTD, the RPO and the RTO come in. These are very important acronyms. So MTD is not on this slide. That's your maximum tolerable downtime. That is what is the absolute long we can go without having access to the system or having access to that data or to a third party. The recovery time objective and the recovery point objectives, they all work together, but the recovery time is how quickly do we need it? So that's usually less. So the recovery time objective is usually a, it's a shorter timeframe than what the maximum tolerable downtime is. And then your recovery point is how far back do I need to go to be able to resume operations? This is very important information that you hand over to the IT folks. So everything we've just discussed so far, this is more on the operational side.

So think about all the aspects of your organization, the front office pieces, the back office pieces, the clinical care pieces, the ancillary pieces throughout. You are putting to paper what those critical processes are for each. So a critical front office process is going to look different than a clinical process, which is going to look different than a back office. But you want to make sure that you go across the organization and that's why it's so difficult to do this, right? It's also why it's so important because when you do go across the entire organization, the aha moments we see with doing these BIS is ah, we have a critical system that is really not on our radar from a DR standpoint. So when you take the BIA and you take those RTOs, so the recovery time objectives and the recovery point objectives, and then you go to it and say, Hey, these are the 100 systems that we need. Here's how quickly we need them brought back up, you have us covered right now. It's job in this to communicate what they can support. The next aha moment you will see with these is it can't support every RTO and RPO or every MTD. They can't, and I call it an aha moment because sometimes we assume it can support anything. Let's say you have a critical system, heavily third party dependent.

The maximum tolerable downtime would be eight hours. We will start experiencing real pain if the system isn't brought back up within eight hours. What if the best it can give you is 24 hours? Your contingency plan now becomes managing the gap. So let's just say for illustrative hypothetical conversation here, let's say it's your EHR or let's say it's a patient intake application within the ed, we are going to have to fall back to manual processes during that time period in the event, such a disaster were to occur where it couldn't bring the system back up for 24 hours and we really can't handle more than eight hours of downtime. We're now going to have to have appropriate manual processes to handle that gap. And these are, I call them "aha" moments, but they're, it's a really great conversation. We're bringing all these stakeholders together to have honest conversations around what are our needs, what can we reasonably support and what are we going to do to manage those gaps that come about in some areas when we're facilitating these exercises?

Some areas that may be we're just going to sit and wait. We don't have the resources to bring the system back up on time. So we're just going to anticipate that that is going to pause and that assumes that it's a process that can go on pause. I don't want to diminish the importance of any one department. So by what I'm saying is not diminishing the importance, but let's say it's something marketing related and our marketing team set up this presentation, so I'm not diminishing the importance of marketing. They're going to be really high up on our BIA at EisnerAmper, but that may be a case where we might press pause on certain things while we wait for our system to come back online.

In other cases, we're going to have to have manual contingency plans because otherwise we're diverting patients to other facilities. So it's probably very clear why this BIA is so critical, also why it's so difficult to perform a thorough BIA. I'm sure a lot of questions are coming to mind in terms of, alright, how do I bring this to life? There are some key questions that you'll want to answer. Many of those I have already shared here, but I'll bring back into the chat the project management aspect of this. Gosh, I really wish we could invite some of our attendees to speak here because I would love to hear from our B-C-P-P-M, I can imagine that you may be involved with facilitating some of these bia. It's absolutely a project management dynamic because you're trying to crawl across potentially a very large environment with many departments.

It is both art and science when you're doing these bis because you are categorizing your risk as you go. How granular are you going to document your critical operations? In some cases you may take more of an abbreviated kind of aggregated view of different things and in some cases you may truly break down with great granularity those operations, but ultimately there's no right or wrong in how you do it. The key is, are you identifying where those dependencies are, where we need contingency plans, what it can support if you achieve the end goal, how you get there is less important. It's all about whether you can achieve that end goal. But I would say it is a tremendous project management endeavor. We'll often see those emergency management groups, while their role may be more on the crisis management side, they're great to facilitate the effort.

Sometimes it is asked to do it. That can be a little tough for it to facilitate a BIA across a large environment because some of those conversations can be, you may need other stakeholders in the room to facilitate the conversation. Again, internal audit, great place, great place for internal audit to help broker these conversations because you're always bringing that risk lens and helping prioritize. So it's foundational. So to summarize, these two passion slides we just went through, there are templates out there. NIST has a good contingency planning template that speaks to what are some core elements of a BIA provides some structure.

There's a lot of ways you can document it. The conversation is what's key, having good quality discussions. You can add some efficiency by facilitating surveys. We've seen some providers leverage ServiceNow and other systems similar to a ServiceNow to help keep this evergreen and to help provide continuous inputs into your BIA. Because that's the next question is, well, how frequently should we do these? And I would answer it like a true consultant. And I would say it depends. It depends, but it's the foundation. So before we build the continuity plan, before we develop our disaster recovery plan, start with the BIA.

Cody Loup:Yep. So that brings us to our second poll question. Which of the following best describes the purpose of a business impact analysis? You give everyone another minute and I see just through the chat some people that have taken on the task to start the business continuity plan and it's just going to touch everyone in your organization is honestly one of the hardest things about this is just so many silos into healthcare plan. I think I what we talk about next, we'll make it a little bit more helpful in order to do that just because it can be so hard just to try to manage your entire organization from one person, but there's ways we can make it a little bit more digestible. It's the same thing if anyone here has ever tried to take on an ERM, it is the same headache as how do I possibly go touch everyone and mitigate all the risks the organization has. That's the difficult part. That's the struggle that most people have.

Paul Douglas:I love the feedback we're getting in the chat. I'm going to go through a fuse. I mean Lindsay's on point. I mean they're doing theirs quarterly. So that's great. And that probably speaks to the complexity and the needs to continuously update because new systems are always being introduced. New third parties, I mean, think about how many new third parties a year you bring in. You want to make sure that those dependencies are being captured in your plans. Amanda, I love what you closed your statement out with. It's better than nothing. Agree. This is a game of incremental progress. Anything's better than nothing and you're never in a perfect state. Even if you get to the point where if you're like Lindsay doing it quarterly, you're never at a perfect state. So Amanda, I love the comment it is better than nothing and this is all about incremental progress.

Ashley, thank you for your role. That's a big health system with a lot of needs. I'm sure you stay rather busy. I see you're also located in South Louisiana, so you know about those non-adversarial disasters, the hurricanes that head our way. Great. Okay, so I think we have all our answers. So on the B, there was a couple trap options. So one of the trap options is to test IT systems for cybersecurity vulnerabilities. So much with the move our environments are so digital at this point. We think of business continuity and disaster recovery very much as an IT exercise and cybersecurity as a very present disaster scenario. Mainly ransomware, but ultimately the BIA. It's focused on those critical business operations and deciding what the needs are. So then that piece can come next. So then we test the system, we test the system after we figure out what the needs are because that test now has parameters. This is the context in which what would define a successful test. So the BIA is helping define what a successful test would look like. And then lastly, we do need to train people. We do need to train people. So we like to say there's no one wrong answer. We're just kind of presenting how this could theoretically work in secrets together.

Cody Loup:Alright, so this is I think an easier way to digest this, right? A lot of us, we understand the idea of a business impact analysis, but how do I bring it out? So Amanda, as you said, it's a start on trying to talk to everyone in your organization, but how do I present this to them? This template is one that I developed a little while ago and I think it's had a lot of success because it's something I can put in front of the organizational leaders that I'm going to interview before I go in there. A lot of times, what are you going to get pounded with? The second you put a calendar invite is what do I need to do? What do I need to prepare for? And if you don't give them something before you can sit in this meeting room and I'm sure if anyone has ever asked someone what their risks are, it's like asking somebody what do you do?

Imagine if someone sat down for you and said, what do you do? It's a hard question to answer. It's hard for them to even understand their risk. A lot of times you'll get, well, I don't have any risk or I don't really know what my KPIs are. I don't really know what my activities are. This template has kind of helped that I've seen when I give this to an organizational leader, they get an idea of what we're trying to do. Once they have an idea of what we're trying to do with the BIA, then it kind of fills in itself. So the first thing is a service area. Let's think if we're doing this for finance, right? Finance has more than one activity. That activity could be closing month in, right? That's an activity that's going to be operations. Depending on how your organization is set up, they may monitor payroll, right?

That's another activity. So once you start filling in those gaps, they get the idea, okay, you're asking me for what are our big operational areas within my group? And then after that you say, what do you depend on? And a lot of times you're going to get the obvious ones, right? If you paychecks for payroll, you're using Epic for your electronic medical record, it's going to be easy for them to see those. But what's funny is I'll often give this to someone and what they'll leave out and then I ask them is they leave out outlook. Outlook is huge for most people. That's how they're emailing people to tell them what their tasks are. That's how they're monitoring it or teams. Let's just be honest with ourself. If Outlook and teams was truly out for your organization, that is going to disrupt what you're doing.

That needs to be monitored there because if Outlook goes out, if teams goes out and you're working remotely, it's a simple fix. Do you have at least everyone on your team's cell phone to be able to contact with them? If that's a yes, then you can monitor it. But if that's a no, well then you need to get that because if Outlook goes down, you actually are going to be disrupted. So there's certain little dependencies that this will highlight that they don't even think about. What would happen if that goes down. That's another area where these bis have helped is just what is that organizational leader in finance or an accounting? What are they overlooking? And then it also defines what that max tolerable downturn is. That's your survival. If we don't have abnormal operations at this time, we've got to do something else because the organization is folded.

And what this highlights as well, it's a formula, right? When the RTO, which is what it or whoever owns that system application tells you it can be up. If that answer is eight hours but you say you're four hours critical, well that's when you know need to have a manual contingency or another contingency plan. What it also helps highlight is Paul, we don't want to rag on marketing, so I'll rag on what I used to do and what I kind of consult with is internal audit. Internal audit in this is usually not going to be important for what we do in our daily operations. Our daily operations is making sure we're within regulatory standards and compliance. We have financial risks mitigated, but in a true disaster scenario, we can pause that. But I can speak to what I did for a previous organization that's been talked about a couple times in the chat.

When I was working for internal audit there I was there for COVID. A major disruption was the supply chain issue. We needed PP and e, we needed masks to be made. We needed garbs to be made to protect people. Internal audits, since we were in operation that did not necessarily need to be currently working in our normal capacity, we were able to fill those gaps for supply chain. We actually were able to go to a location and help make that PPE equipment. So that's where you can get an idea of, okay, some of these departments that maybe have functional areas that are five days business days as we show here is maybe not as critical. They can kind of take on some of that mandatory task in some of your other areas like supply chain where they can't have disruptions. So that's another way you can cross-reference everything, right?

When you get this organized and it's all can be digested in one place, in one Excel file or wherever you want to manage it in a template similar to this, you now know how you can fill some of those manual gaps. So that's another useful way in why you want to develop a consistent template. So everyone is kind of measuring apples to apples and you'd be surprised at what you end up seeing here with all the third parties, all the IT dependencies you have that you would never would've really been made aware of. And I think it's eyeopening honestly just is something to go through for those operational leaders because the higher up you get, you kind of lose sight sometimes of maybe what exactly is happening under you. It kind of opens their eyes again to okay, wow, I didn't even realize we had risk there.

Wow, I didn't even understand we were doing that. So it's a good activity for the operational leaders, not just from a BCP scenario, but just from an idea of making sure that they're current on where their operations are in their actual area. Alright, so now when we've got the BIA done, where does that lead to and what does that let us know where we are in our actual business continuity maturity? Level one I've seen less and less what level one, this is ad hoc, no formal B-C-P-B-I-A documentation at all from the healthcare arena. Some people in here may be thinking that's where they're at, but they're usually not. And the reason I say that is, like I said earlier, for us people in South Louisiana, I know we've got a couple of us on here, what happens with a hurricane? It's not just we're going crazy and we don't know what to do.

We have team A or team B or tier one team or tier two team, however you label it. Your hospital, you have that plan in place, right? The team A is going to be there for 24 hours, they're going to take shifts, they're going to sleep at the hospital until that event is completed. That is A, B, C, P, right? I mean you may not call it that, but you have that. I mentioned power Allis earlier. You have a plan for that. So in the healthcare arena, I don't think many people are at a level one in other organizations, yes, or healthcare. I think everyone has at least got to level two. I think this is still not the most common that I see, but I do see this, right? And this is developing, this is initial assessments underway. This would be okay, you have the tier eight, team A, team B, you have power outages, but it's actually not really formally documented anywhere.

It's just kind of an understand process that everyone takes on. That would be level two. What I see most commonly is level three, right? It is defined. There is a business continuity plan in place. It is written down. However, is it actually tested? Y'all Abra ever actually try to penetrate your business continuity plan and shut down a system and see how well someone can respond? Probably not. That's level three, but at least it is documented. If you asked a random employee, do you have a business continuity plan on level three? They may say no, it does exist, but people aren't aware of it. Level four, I am starting to see some people on level four and it's managed. There's regular testing and there's governance in place, right? You're actually trying to break it. You're actually managing it, you're making sure it's live, you're making sure it's tangible.

And when I say you, I mean whoever's managing the business continuity plan. So you've got a bunch in this chat that's level four. You've got that person aware of it, you've got that person making sure that it's live and they're constantly monitoring it. That's level four. What is level five? What's the ultimate goal? Everyone wants to do what level five is, it's embedded in your culture. What does that mean? That means that let's say someone in finance adds a new system for payroll. What are they going to do? They're going to go make sure that they let the person in charge the business continuity plan. Know at that moment. That's what embedded in your culture is. They're not just updating their current processes for what they do. They know that anytime there's a material change in their operations, they need to update the business continuity plan because that's an important area in case there's disruptions. That's what it means embedded in your culture. That is hard to get to. I think everyone continually strives for that. I think that'll be a constant battle even when you get to level five to stay at level five. But if you can get to that point, then you're truly managing it how it should be managed, right? The actual goal.

Alright, that rolls us into our next polling question. What does recovery time objective represent? All right, I can see through the q and a chat, it looks like some people are doing some penetration testing, they're constantly making sure the backup systems are there to perform. It seems like a lot of people are working on level four. That's look, that's the most common is on level three. Trying to get to level four that I'd say is the most common for health systems and it's just a constant battle. And the reason it's so hard is in healthcare we just have so many different areas and they don't necessarily talk to each other and so it makes it hard to have one of these business continuity plans in place. Another thing that makes it unique to do a business continuity plan is you get so many well at the pins answers from your organizational leaders and payroll is the easiest way to say that is payroll can say, well if my payroll system goes down 14 days before payroll not really that big a deal. I'm not even that worried about it, I'm going to let someone know. But if it goes down 24 hours before payroll, massive deal, right? So you've so many of these wealth depends answers. So that makes it kind of hard to define and manage, but that's a headache that everyone has to experience.

Do you ever want about one more minute to answer here? Another thing is that I'm interested to see how other people do it is I, I've done it both ways where it is involved in the actual operational call. So you'll have an IT representation when you're meeting with finance, when you're meeting with accounting, when you're meeting with marketing, when you're meeting with operational leaders because that way they can answer the question of, okay, is there a difference between our RTO and our Maxwell toggle downtime? But I've also seen it where you meet with all the operational leaders, all finance, all accounting, and then you bring that to it and then it can say, okay, I see what everyone's telling me. They need the system back up in time before it's mission critical. And then they say, this is possible, this is not, I'm not sure which way works better. I think it just depends on how in tune it is with your organization. But I'd be interested to see on if more people are bringing it in during the process or do you show everyone else's plans and ideas after the fact to it.

Alright, what does recovery time objective represent? The maximum acceptable amount of data loss. That would be your RPO, the maximum acceptable downtime for a critical function, the time needed to notify leadership in the incident. So it is the maximum acceptable downtime for a critical function and it's almost the same with MTD. That is the maximum acceptable before it completely becomes critical organization. The maximal accessible downtime is for recovery time. It's really what it says is the maximum time that they can get it up. So that is correct answer. It's kind worded in a way is which is confusing, but that really is your gap, right? The gap between your RTO and your MTD is what you're worried about for your business continuity plan. Alright, some of the components.

Paul Douglas:Yeah, so this next section we'll cover some of the continuity plan components and then we'll go into some areas for internal audit to consider. We know we have a lot of internal audit folks on the line as well. Business continuity plan components can vary. I am a big proponent of tailoring to the needs of the organization and doing it in a way that's actually going to be helpful. There is both a compliance side to this. We need to make sure that we document in such a way that we can pass the expectations of regulatory examination because from time to time when things do go wrong, folks that we want to make sure that we keep happy, they'll come in and they'll ask to see our business continuity plans. And so we want to make sure that they're adequately documented, but we also want to make sure that they're helpful. And so some components, I think a simple way to think about it is you want to have a strong connection between the results of the BIA and then what the subsequent contingency plans are. Sometimes you'll see the results of a business impact analysis nested within your continuity plan itself. So maybe at the top, so structurally at the top of the continuity plan it could say, Hey, and I think someone in the chat had mentioned they split their out by cost center. I like that approach.

It's a nice way to think about structurally who would have an individual continuity plan is perhaps by cost center across the organization, but you have one standardized template that you're all operating off of. I saw another individual had mentioned that they're utilizing Microsoft forms. We've done that as well. You can get pretty adventurous with those forms and building out some dropdown menu selections and other capabilities. So we've done that as well to facilitate, but I like standardizing. So whatever that customized template is for you all standardize it so that way you can really do some nice things with the data you're collecting. You can help aggregate these things and it helps prevent this from getting overly messy, which I'm sure as you can imagine, this can become very messy very quickly. So have that connection between the results of the business impact analysis, those MTDs, RTOs, RPOs, maybe even put that at the top of, and if we're to go down the path of doing it by cost center for each cost center's standardized continuity plan, maybe have that at the top. This is what we have to support. This is maybe where some of our gaps are. Then everything else comes underneath. Who are the key contacts? Who are some of those manual processes that we want to be training our people on in advance? Not real time in advance. What are we going to train our people on to be able to support should we have to activate the plan?

Cody, I say we transition into some of the internal audit topics.

Cody Loup:So we keep mentioning why internal audit is such a good bridge for this. I have an internal audit background. That's where I started my career was internal audit and healthcare that now do co-source and outsource internal audit here with EisnerAmper and why I think it's such an easy area to get involved in your business continuity plan is they're already doing this to some extent. Your internal audit team is already doing an annual risk assessment with most of your organization. So what does that do? That does twofold, right? It makes the internal audit aware of a lot of the key process areas already, right? Because when they're doing that risk assessment, they're already sitting down with your organizational leaders and they're asking them what their risks are and in turn they're finding out what those key process areas are, right? Because to know what a risk is, you have to know what process area that goes with.

So they're already going to have an understanding of what the risk are in your organization. They're going to have a basic idea of what the importance lies for your business continuity plan. Other thing that does is they know an easy way for them to have an understanding of who is in your organization and also doing a BCP. It's hard because you've got to somewhat be a jack of all trades, right? You're not going to be an expert of every area in your healthcare organization. But internal audit, I don't want to brag on myself or all the internal auditors in here. We are the jack of all trades, right? It's part of our job duty to be able to understand rev cycles. We got to understand payrolls, we understand compliance. We have to. So we have that basic understanding of all those areas to where it makes documenting these BS and then developing the BCP from that possible periodic updates.

You can put that on the internal audit plan. That can be something to check in on if you want this to be a quarterly review. That can be part of what internal audit does they check in to make sure that these business impact analysis are up to date internal audit. I'm already doing that on every engagement. The first thing we do is say, what policies do you have in your area? And we make sure that those policies are updated and signed off on. That's the same thing for your BIA. Is it up to date? Is it a living breathing document or is it one of those lazy policies you slapped up and you never updated it? Then it's just a piece of paper. So that's something, once again, internal audit has great experience with, they're going to be up to date with regulatory expectations. If there's a regulatory change or a regulatory update that BIA needs to be updated, right?

Because you need to make sure that your new business continuity plan and your key process areas match what that new regulatory expectation is. So it is an area of your organization that's going to be aware of updates because they're constantly tracking for these updates. And they can provide not just assurance, they can provide independent assurance. They are someone that's within your organization or someone you outsource to that is truly independent. They can truly weigh is this business continuity plan reasonable? Is it feasible? And they can give you that from an independent source to where you're probably getting a real type of answer. It's not something in which it feels forced. So they're putting something that's easy on paper because they know it's manageable, it's, it's just really going to be something that's adequate for our operational standards.

Alright, conducting a business continuity plan audit. Before I do this, there was a great question, Paul. I'm going to give my answer then I'll see what you think from an IT perspective when an organization's typical backup is to say it deal with this, what should it say? I think it's plan should have pushback here. I think they should give an adequate answer on what is reasonable to get the IT systems up to date. And when that answer isn't sufficient, because let's say if it's eight hours and mission critical is four, to then push back and say there's nothing from an IT perspective, we can do, this needs to be managed by the operational team because from an IT perspective, we cannot manage that. And I think sometimes it does fall on it. I think it's just have realistic expectations and realistic answers where it does stand up and say, we can't manage this, right? We cannot fix the problem. It has to be fixed from the operational side. And that's someone from operations saying that. So I would like to harp on it as much as I could, but I think it is not fair to them to be able to manage all this because some systems can't be brought up in enough time that is actually needed for a healthcare company. Paul, I'm interested from the IT perspective what you think.

Paul Douglas:Yeah, it's a resource question. Let's say we don't have the capabilities if we were to invest more either from a, it's always a people process technology dynamic. All three require adequate resourcing to bring a system or an environment back to life within let's say it's a really aggressive timeline, high availability environment. It becomes a resource question. And so if we can communicate, this is what I always encourage. I do primarily work with our CIOs and our CISOs. If we can communicate that based upon the existing resources we have, this is what we can support and this is the additional investment we would need to need their people process or technology to be able to shorten that timeframe. And so then it becomes just a budgetary exercise and what we want to prioritize. In some cases it may be like, you know what, we're going to press pause and we'll fall back to manual processing. But that's how I would approach that conversation is what can the existing resources support and then what an additional investment would be needed. We do want to make sure everyone gets their CPE today. So I think we have one more question, right? Savannah? Do we want to jump ahead and knock out polling question five?

Cody Loup:We'll jump ahead because as a CPA, this is important to me too as well. We'll go back to the previous slide, but we'll give everyone a

Paul Douglas:Same, make sure everyone gets their CPE. Yeah,

Cody Loup:Yeah. And this is a trick one then, because we haven't gone over this answer. So what is the following common gap identified in PCPP audits? So before we go over it, let's see if anyone can take a good stab at it.

Paul Douglas:This one Cody, feels like a question you would see on A-C-I-A-C-I-S-A-C-I-S-S-P exam. There are continuity certifications as well. This feels like one of those questions that you might have to answer.

Cody Loup:Alright, looks like we have most significant here, so we will go back a few slides here and we'll go over that answer. Conducting a BCP audit, and I'll go quick than this is what do we want to do? What does an actual audit look like? If you want to get involved and say, where are we today and what do we need to make sure we're hitting review documentation, see what's out there for your business analysis and what does it look like? Is your business continuity plan on your company website, on your internal share drive? Where is it? Where can an employee access it? Right? I know in ours we have our intranet site. There's a link to it. Where is it in your company? Is it in a manila folder that no one knows about? Or is it a living breathing document that anyone can access? Look at what the scope and objective is of your bcp. What is the purpose of it? What is the breadth and the overall objective of the BCP? Because yes, it's a word, but it doesn't mean the same thing to every company.

Verify the roles and responsibilities. I want to go to that one. Do you have a BCP leader? Is there someone that is in charge in your organization to say, we need enact the BCP, or is every operation in every silo and control of their own? It can be managed either way, but I think it's important for you to know, evaluate the test, evaluate the penetration testing. Are you trying to actually break? Are you trying to actually see it's adequate? If it's even manageable? Is it possible analyzing the third party dependencies? I think that's the most important thing you can do. And to go with that, the fourth party dependencies, right? I think that's a huge value when doing this, is to see who you're depending on to run your company. Have you had any incident responses? Look in that. See what recently have you've actually had to do as it relates to your BCP and review your recovery strategies. And this is the common gaps, Paul, let you take this one.

Paul Douglas:Yeah, yeah. We've covered a lot of common gaps. So the importance of performing that BIA, if we have a strong foundation with the BIA, we can continuously update that, whether it's quarterly, annual updates, finding a way to do it efficiently, governance, very important. The more complex, the more decentralized a topic is. This is a highly decentralized topic, the more stress on your governance. So really strong governance, meaning we need to have a clear understanding of who's responsible for what. We need clear standards and expectations, so all those decentralized units can be following the same protocols. Infrequent planning or testing. It's really difficult to do thorough testing. Really difficult to do thorough testing because you don't necessarily have the opportunity to say, you know what? We're going to take down our EHR because we don't see patients on Saturday. Well, you probably still do if you're a inpatient acute care facility. You see patients seven days a week. So it's hard to find that perfect moment to take your systems down. So you're having to test in other creative ways to get that level of assurance on how resilient our systems truly are.

I think this is a good moment to bring us to a close. With that, I would say Cody and I love helping organizations with this topic. We have helped provider organizations, third parties of providers in different ways to, I had mentioned that we're big proponents of having custom bis, custom contingency plans to put you in the best position to be successful. That's something that we're very passionate about. So whether it's knowledge sharing or helping bring some of these dreams to life, we would welcome the opportunity to keep this conversation going. Thank you everyone who joined today, and we hope to stay in touch.

Cody Loup:In closing, I would love to hear from anyone on questions, or if anyone just wants to talk about what they're doing at their organization. I love to hear more. I love to learn from others just as much as I hope others can.

^{Transcribed by Rev.com AI}