in this video, we're gonna expand on enterprise risk management and talk about the specific considerations for enterprise risk management. When you're thinking about the cloud.
We're also going to talk about the impacts of those Cloud Service models on governance,
and we will evaluate the ramifications of the different cloud deployment models that those also have on governance, which dovetails back in enterprise risk management.
This life summarizes key elements of enterprise risk management that you're gonna want to know for the exam.
I'm gonna dive deeper and each one of these. But before doing that, I want to give you a little background on enterprise risk management. Just as a general philosophy in case you don't already have that
missed 839 provides a good, structured way to look at and understand enterprise, risk management and even implemented within your organization. If this is something that needs to be done if you don't have a background in enterprise risk management, I recommend that you skimmed this publication just to become more familiar with the basics.
It's not gonna be specifically referred to on the CCS *** test,
but it will give you a better appreciation and understanding for the fundamentals of enterprise risk management. In case you're confused with any of the topics that we're talking about here
in this particular video, we're gonna gloss over the four key activities that the publication outlines regarding risk management as a process
over on the right, you can see a nice diagram that highlights frame, assess, respond and monitoring and how they relate to each other.
And at the center of it all is framing risk. This is where your organization sets its own risk tolerance. That tolerance is going to be highly influenced by many factors, including the industry of the company, the size of the company's, the regulations and laws that the company needs to adhere to.
Bigger companies usually have more regulation and laws that they have to keep track of
different industries. Same thing. Keep in mind, the risk tolerance is going to set the tone for a lot about a company, not just the technology security aspects, but also financial decisions the company makes who they want to invest in. What kind of investments do they want to make? How much risk are they gonna assume in those investments?
It could also influence business operations.
Who are their partners? Who are their suppliers? Can they work with people in certain countries? Are they going to be excluded because the particular industry they're in or the main customer line that they're working with doesn't allow that Once you have a good, clear vision on the risk tolerance through the framing, you're gonna then assess the risk
identifying the threats and vulnerabilities. And what's the probability of
those things being exploited?
This could be done using qualitative methods,
for example, ranking something as high medium or low or quantitative methods where you actually have hard numbers. Often this is done in terms of dollars, but could also be reflected in terms of lives impacted. If you're a power company and there's an outage, there could be some significant impacts.
Too many lives
medical companies, health care companies, lives can literally be impacted. Defense companies themselves, lives could be impacted. Sometimes they want to take lives. Sometimes their products are to defend and save lives as well.
So the specific methods you use, they're gonna vary again by the company and ultimately this gives you a nice prioritized list, a way to go about determining of all those threats, vulnerabilities and probability of exports, which our highest priority in which are the things that we want to go after.
So Step three is where you respond to the risk. This is where you apply that risk tolerance you define when you were framing everything and you look at all the risks you identified when assessing
and you determine are you going to manage the risk, transfer the risk, accept the risk, avoid the risk. We're gonna dive a little bit deeper in these coming up.
But finally, Step four is where you're monitoring. This is the follow up and ongoing processes that take place to ensure you are doing what you said you want to do. And it's being done in a manner of detail on diligence that's acceptable. So when you're doing these audits, it might include things like
making sure vulnerability scans air run on a specific frequency
off certain systems that were identified, ah, that meet a certain level of criticality. It may include ensuring that vendor risk assessments and suppliers assessments are being performed on a regular and ongoing basis.
It could really vary, but I think you get the point. It's Let's make sure that we're doing what we said. We're going to dio
with a background of er m established. Let's pick up and talk about the key tenants of risk management. This aligns with Step three and the nous that we were looking at previously the respond to risks. So there's a few things Weaken Dio. You can manage the risk by having controls, pause processes, policies, procedures.
You could also transfer the risk. This is often enabled by cyber insurance, so you're transferring the risk
of financial impacts. Just keep in mind, particularly when it comes to financial cyber insurance, that the risks are limited to the financial impact that you get directly as a result of the breach. And it doesn't take into consideration financial impacts of an indirect nature, such as
costs to your brand
loss of customer trust and those kind of things.
What else can you do with risk? Well, you can accept it, and if you have the risk tolerance, that may be very adequate, and you just say that it is what it ISS, and we are willing to accept that risk
and finally, you can all out avoid the risk in its entirety in the context of cloud. We're talking about situations where you make the decision. Your company makes the decision that certain types of data are not going to be in the cloud. You're not gonna put certain mission critical systems in
the cloud that, let's say, the public cloud. Maybe the decision is
we want this on premise in a private cloud that is disconnected from the general Internet. And so that's the most were willing to do. And we're going to avoid the various risks that come with a SAS provider for hosting applications and so forth.
Key terms, toe understanding. This is risk tolerance. That's the amount of risk that leadership is willing to assume
as well as residual a risk. So that is the amount of risk that you've accepted those different things that you said were okay with that. Let's say we're a smaller company and we're using a SAS provider,
and there may be not so well established, and we know there is a risk that they could go under and we might lose some of the information that we're storing with that sass providers say information about our own customers. Uh, that might be a risk that we can just accept and tolerate at this juncture in the company's trajectory.
And the point of all it is that there's no one size fits all approach. It's very driven by the risk tolerance of the company at an enterprise level, and then you continue to perpetuate those in. Embody those values as you're making different
decisions on the cloud technologies that you're using and you're gonna invest the amount of diligence in activities
to be aligned with the particular data or the processes that you're looking at entrusting with a cloud provider. So maybe you're trusting the secret recipe literally. Let's say this is the secret recipe to Coca Cola and we're going to store with a cloud provider.
Well, that's a very valuable thing for us and something that Coca Cola wants to hold onto
again. That that's a very valuable thing, that it may be considered of a greater value than than other information like, let's say, some historical transaction trends of the different stores that you've had over the period of time. So just keep that in mind. It's about being pragmatic. Oftentimes, as larger organizations,
we'll even build out a matrix of different kinds of assets types, different types of data,
different types of processes and procedures to better delineate what kind of things can be hosted using cloud service and the criteria around that cloud provider in order for them to host things of this more critical nature versus non critical nature versus things that are even of off no critical
type of a role,
just like with security, we have shared responsibilities. Model were also having the shared responsibilities model with risk management. And that's gonna change based on the different service model off the cloud provider that we're engaging with
at the very top SAS, where the cloud provider is going to be accepting ah, lot of the responsibility. Or at least we're going to be giving the cloud provider a lot of responsibility. So in these circumstances, contracts are very important because you don't have a lot of direct control or leverage to enforce what you want above and beyond that contract,
you also with smaller providers, gonna have ah, little more negotiating flex ability, for sure on these contracts.
And, um, just keep in mind your ability and your insights are going to be minimal. Oftentimes the technology there's usually like a Web based user interface or something that gives you the insight. But in terms of understanding the infrastructure, let along the operations to manage that infrastructure, let alone the
facilities in which that infrastructure runs you're not gonna have a lot of insight into that, especially in the SAS provider model
making our way down the stack. We have the platform as a service model, so in this paradigm, the cloud provider is a little less likely to negotiate on the contract than a SAS provider for sure. But you're still not gonna have a ton of control. So getting that provider to be compliant with what you want and be
held accountable for performing the responsibilities that you're expecting of them
is going to be difficult. So one of the things is to consider the contractual attestation that we had talked about in earlier videos
and rounding it out. We have I ask again, just like with Security model saying, within the risk management model, the majority of the risk is now going to be shifted over to the consumer from the provider. There's still things that the provider is gonna have to take care of, such as the physical security off the facilities hosting the machines,
such as the core network backbone,
right? So there are certain risks that the providers gonna handle for you. It's comparable almost a Ziff you outsourced data center. But a key difference here with it being cloud, as opposed to just announce Sourced Data Center, is that we have orchestration and automation in the mix,
and that's exposed to us through a management plane of a Web interface portal.
So there's certain risks there, just like with security that are squarely in the sights of the cloud provider.
And now let's take a look at the deployment models and their impact on enterprise risk management.
Public Cloud is where you're gonna have minimal control or the providers internal operations.
This includes things such as how they managed facilities, other customers that their allowing into that public cloud
and even items like labour sourcing. They may be outsourcing the labor to manage the facilities,
and what that all means is your ability to govern their operations is very metalized. In fact, you're probably not gonna have a lot of leverage to negotiate that contracts, but you're gonna want to rely on them very closely to identify the risk gaps. And from that point, then you use your own internal governance methods to mitigate those risks. Caps
using things like we talked about. You can manage it, transferred, accepted or avoid it.
Private Cloud, if it's fully in house and fully managed, is significantly different because in that circumstance you are your own customer. But it's not unreasonable to see situations where an enterprise will have a private cloud. So there the Onley user of the cloud and the business and units within that enterprise
are the only tenants operating in the cloud. However,
it's being managed by 1/3 party. The other things you want to keep a real look out for when we're talking about risk management of a private cloud, especially when it's 1/3 party, is ensuring that there are. The contract stipulates different things in there that you need to be done.
Service level agreements, often times. That third part is going to do what's in the contract,
but don't assume they're going to go above and beyond the contract because again, when you're talking about with third parties, the contract really is the basis of the agreement. So we're talking about things like updating the hardware infrastructure,
applying patches and even bringing new technologies in the cloud latest and greatest things that are going on. Maybe you had a public cloud and it's solely virtual machines, and it's an agreement that was put in place five years ago. And the company that's managing that cloud
hasn't even brought in or upgraded to provide a capability that would allow you to use containers.
You want to stay away from that and include certain provisions that ensure that the technologies that they're providing and supporting in that cloud are competitive, reasonably competitive with the industry.
If you get questions on the exam, pay close attention to who owns and manages the infrastructure off that private cloud because there's a lot more involved when it's a private cloud managed by 1/3 party,
then when it's a private cloud where you company itself is managing it and is in sourcing the various operations and finally we talk about the hybrid and community cloud. This is a situation where we have common controls amongst the different participants. All the tenants are assumed to be relatively friendly here, so
some of the delineation between the different tenants doesn't need to be. A strong certainly is if you have a public cloud.
But now we have to look at and multiple sets of contracts to include some sort of ah, standardization amongst all the participants. Everybody's doing their fair share, and they're all living up to similar standards because, just like a chain is only as strong as its weakest link. The same situation rings true when we're talking about a
community cloud and that
compliance is only going to be a strong as the least compliant when it comes to managing that cloud.
So in this video, we talked about enterprise risk management in all aspects, and we really drilled into enterprise risk management from the perspective of the cloud,
the impacts of service models on governance, as well as the ramifications that different deployment models have on governance and enterprise risk management