- [Instructor] So we've talked a lot about all
of the different things that are happening
in an organization.
Strategy, objectives, processes, external requirements,
internal requirements, business continuity requirements,
IT risk being created places both within technology
and outside of technology.
And as we start to think back to the types of governance
that we talked about earlier in this module,
we really want to start to focus in on the risk governance.
And that's really where enterprise risk management comes in.
So as we start to think about how we're going
to manage risk consistently throughout the organization,
regardless of department, regardless of type of risk,
enterprise risk management can help us really set
that tone at the top
and say, "This is how we're going to manage risk."
That also includes risk culture, standards,
how we talk about risk, how we deal with risk.
And if we can make risk management those adjectives
on the left,
so we can make it comprehensive, all different types
of risk, the entire organization, we can make it complete,
accurate, auditable, and compliant.
That will really help us
to actually do the things on the right hand side,
achieve our objectives, create value,
and of course manage risk.
If we do it consistently across the organization,
that's going to help us achieve our objectives even better.
And as we talked about earlier, with the goal of more good
and less bad, that means not only have we created value,
but we can create more value,
and we can create more value, easier, simpler, quicker,
and at a cheaper price.
And that really is going to help us achieve those objectives,
overall.
As we look at our organization,
we're going to take a look
at our organization's risk profile.
So this is the overall risk posture for an organization
that's reflective in the risk activities
of that organization.
So this is going to be things like internal changes,
the execution of an IT project all the way up
to a new product or service, an organizational change.
How are those things impacting our risk profile?
Maybe we're talking about mergers and acquisitions,
or maybe we're talking about things on the outside.
So external changes, changes in competition,
changes in the industry,
changes in the geographical location
that our organization serves or that it's located in.
All of those external changes are going to drive
that risk profile, right?
So that's the overall risk posture of our organization.
There's more regulatory action
that's going to increase our external changes.
And if there's less,
that's going to lessen our risk profile, right?
So all of those things are going to be constantly varying
that we're going to make sure we need to take into account
as we look at the risk profile of an organization.
We're going to look at environment changes.
So again, things like competition, things like
the reputation of our industry, things like
the actual environment that we operate in.
So like we talked about earlier with business continuity,
is our data center located in a place
where there are environmental issues, earthquakes,
tornadoes, hurricanes, tsunamis?
I'm sure I'm missing a couple there.
But things that we want to understand that are changing
within that environment as well.
We also want to understand the supply chain.
So like we talked about with as a service providers
or as we start to see a trend in offshoring some services,
moving services from currently managed by our company
and outsourcing them.
All of those things are going to change the risk profile
of our organization.
Lastly is risk awareness.
So like we talked about with risk culture, how do we ensure
that the way that our employees
or anyone acting like an employee, like a contractor
or a third party provider, is making sure
that we're identifying risk early, we're doing it in a clear
and transparent way, we're dealing with risk in a way
that's appropriate for that risk.
All of those things can drive your risk profile up and down.
Now, once we know what the risk profile
of our organization is, right?
All of these things have changed the risk profile
and can change the risk profile,
but we're going to get a result at the end.
And maybe you measure this through numbers, right?
So you're going to say it's a 78 out of a hundred
and maybe you use qualitative language like it's critical
or it's high.
Whatever you do for your organization,
you're going to say, what does that mean?
How do I contextualize that?
Is this correct?
Is this risk profile appropriate, right?
And that's where this next concept comes in
of risk appetite and tolerance.
We talked a little bit about this before
in the concept of policies,
but we'll dive deeper here
to really center in on risk appetite being the amount
of risk that an organization is willing to take.
Now, most organizations will have different risk appetites
for different types of risks.
I used the example earlier of a data
and security incident where it's very unlikely
that a organization will have any sort of appetite
for that risk, right?
You're not going to see someone write on a piece of paper
that they're willing to deal
with 17 security incidents a year.
That would seem like a company I don't want
to personally do business with,
but it certainly doesn't seem like a great business decision
overall, given the cost that we know
to, both, your organization directly
and to your reputation indirectly.
But it's going to vary a lot more
when we talk about the different type of risk appetites
that exist, the risk appetite related
to emerging technology, regarding sensitive information
regarding investment risk,
regarding things as simple
and as small as do you want to buy the endpoints
that you provide to your organization?
Do you want to lease them?
Do you want to do a bring your own device, or BYOD model?
All of those things have some sort of threshold
with the most amount of risk
that an organization is willing to take,
and that's really where your risk appetite is.
Now, when you look at something like risk tolerance, we call
that the variation of risk
that management is willing to allow.
Now, this is applicable in some instances
and in other examples,
it doesn't necessarily make the most amount of sense
to actually apply that concept to.
But a non-IT risk example is thinking about
enforcement of speed limits.
So when you're on the highway,
and if the speed limit by me, sometimes it's 65,
sometimes it's 70, there is a tolerance
that enforcement can take,
where if the speed limit is 65,
the police officer's not going to pull you over if
you're going 66, right?
Maybe the the sheriff department by you, it says as long
as you're going under 70, that's the tolerance
that we're willing to to deal with, right?
But at some point you have to draw the line
and say, this is too much.
This has reached a level that we are not willing to allow.
It's possible that the risk tolerance might be
around acceptable levels of risk.
It might be around your risk appetite.
It's just going to depend again on the application of
how we're measuring that risk and where we're measuring it.
And then, lastly, is risk capacity.
Think of this as the absolute maximum amount of risk
that an organization can take on
before it truly becomes detrimental.
Your risk appetite should be
under your risk capacity, right?
It would be very dangerous if
every time you approached your risk appetite,
you would be approaching some sort
of truly catastrophic outcome for your organization.
But, you want it to be low enough, right,
that we're managing risk,
but not too low that we're seeing an issue with the amount
of resources needed to deploy that, right?
So, there's a balance here that we're looking to manage.
And they need to be thoughtfully set.
Again, it's not as simple as Bob
or Jane saying,
"This is what I think our risk appetite should be."
A lot of times it's qualitatively designed.
A lot of times it's based on kind of starting
with regulatory requirements
and then working down from there.
I'm going to walk through an example here.
This is very qualitative in nature,
but I think it's very easy in this way to see how all
of these things are aligned.
Think of the white line in our example here
as the actual data that we're seeing, right?
So maybe this is
something like the number of open vulnerabilities,
or the number of open problems.
So a lot of times, problem management
in the IT sense, meaning something that's not a small issue,
but it's not an incident, right?
Kind of that in-between thing that we don't want to start
to grow into an incident that can affect availability,
or affect people's ability to do their job.
But it's not something that's small
and easy like for one help desk person to necessarily solve.
So that white line is showing
that there's variability month to month
in the reporting of these things.
I'll use vulnerabilities as my example.
So, in month one, we saw, let's just call that 18,
but by month four, we saw that jump to 35.
The orange line is our risk appetite.
So in our risk appetite statement related
to vulnerabilities, we have said no more than 32,
let's call these medium risk vulnerabilities can be open
at any given time, and that's based on the resources
that we know we have to solve for vulnerabilities.
And it's based on like the risk level
that we've seen in some of our competitors
where if they've had more than 32,
we know that they're more likely to have issues
with their systems, right?
Whatever method we used to come up with that number.
And you can see here that it's been variable.
There's been months where it's been below,
there's been months where it's been above.
But once you cross that risk appetite,
that's saying we have surpassed the amount of risks that we
as an organization want to take on.
And so it's likely that as you're looking at this data,
and as we get into to the type of metrics
that you can measure this with
or the types of things that those metrics can show you,
once you get above that risk appetite,
you're going to need to take some action.
We're going to need to see something be put in place
so we can get that number back down.
Thankfully in this example, by month five, you could see
that it's come underneath that risk appetite value again.
So, thankfully, our actions in that month really did work.
Now, one of the things that I didn't see
in the Osaka material that I think is really important
to talk about here is this yellow line
that I've put into place.
And this is what I want to just generally call
the alerting line.
And again, we'll get into more details
as we talk about the types of metrics
and the examples that we have of those metrics as well.
This alerting line is going to be important
because it's going to give us early notification
that there are issues potentially going on with this thing
that we're measuring in relation to our risk appetite.
So let's use this vulnerability example.
You can see that in month one we were okay,
and in month two we crossed that alerting line.
To me, what this means is we have some sort
of escalation path that's been established
that when we report in month two, this is going to some sort
of governance group, a committee, some sort of gathering
of people, a subcommittee to something, right?
And this is saying, hey, we're starting
to see trends in a way that we don't like.
We're giving an alert to this group.
You might not require, say, formal action plans,
and you might not require the person in charge
of your vulnerability program to speak
before the committee in a minute recorded session, right?
But we're saying, hey, like we think this is concerning
and we want to dig a little bit deeper.
And you'll see that, you know, here in month three,
there's a little bit of variability.
Did it improve?
Yes.
But you might want to dig deeper
and say, is that due to like random circumstances, right?
Like, all of the vulnerabilities that you found had
to be closed in 30 days and we, you know, we achieved that.
Is there something deeper going on?
Are we finding vulnerabilities
at a faster rate than we're patching them?
All of those key things, right?
If you don't have that alerting line,
so pretend that line doesn't exist, that means that as
that variability exists,
and as you can see that there's a clear trend
between month one and month four
where these vulnerabilities increase,
you would not know about that until month four.
And as we talk about things like risk culture,
and we talk about things like proactive management of risk,
is waiting until month four,
where it crosses your risk appetite,
which is literally saying,
we do not want to take on this amount of risk,
really something that we're going to say is a proactive way
to manage risk?
To me it's not, and that's really where
that yellow alerting wine really comes into play
and I think is really crucial when you look at how
to report against your risk appetite.
I want to call your attention as well
to the blue line that's on the top.
It's currently sitting at 40, and that's your risk capacity.
So as we talked about, that is literally the amount of risks
that, if you took on more than that,
would be detrimental to your organization.
So in this case, we've said if
we to have 40 open medium risk vulnerabilities,
like, truly bad things will happen.
Maybe not as applicable in this example,
but I just wanted to continue it for continuity's sake
and think about the type of actions, right?
If you saw that jump from month three to month four,
and you're getting close to that 40,
like we're probably talking in a lot of escalation.
A lot of people are involved in this conversation, right?
And I think that's even more important why we're looking at
that yellow alerting line.
Because again, you don't want to get into a month,
and all of a sudden, you're eight vulnerabilities away
from destruction of some part of your organization.
Not as proactive as we want to be able to manage that risk.
Think, also, about risk tolerance in this example, right?
So are we talking about variability
around the risk appetite, right?
So if the risk appetite set at 32, are we okay with 34
as presented in month four?
Are we looking that that's too much?
Are we looking that that's too little?
Are we enforcing?
Are we not enforcing, right?
So all of those nuances
and how we're managing that risk really need
to be taken into consideration even with something as simple
as how we're managing those vulnerabilities.