- Welcome to Lesson 24: Deep Dive Quiz.
Now, Lesson 24 was all about explaining
the risk management process,
and we did four lessons.
24.1, we talked about risk concepts,
24.2, risk assessment and analysis,
24.3, we looked at risk response and treatment,
and in 24.4, we looked at doing a business impact analysis.
So are you ready?
Let's do 10 questions together.
Make sure you've got a pen or a pencil and a piece of paper.
You're gonna wanna write down answers,
and you're gonna want me to put me on pause
as often as you need.
Are you ready?
Okay, let's get started.
Your organization's Board of Directors
recently adopted a Risk Appetite Statement.
When published, what should one learn from the statement?
The acceptable variation in outcomes
related to specific key performance indicators
or key risk indicators.
The amount of insurance that should be purchased.
Actions that should be taken to mitigate the impact
of an unfavorable outcome.
Or the level of risk
that the organization is willing to accept
in pursuit of its mission and objectives.
Now, read through those again and tell me,
what should I learn from a Risk Appetite Statement?
Well, I'm gonna choose the last one,
which is the level of risk
that the organization is willing to accept
in pursuit of its mission and objectives.
That's the whole reason
why we have a Risk Appetite Statement.
If we look at the other answers,
actions should be taken to mitigate the impact
of an unfavorable outcome.
That's not gonna be in a Risk Assessment Statement, right?
That's really gonna be our risk mitigation
or risk treatment.
And the amount of insurance that should be purchased.
Well, that's really just a risk treatment option,
and acceptable variation in outcomes
related to key specific performance indicators
or key risk indicators,
that's gonna be risk tolerance,
and when we're talking about specific indicators
and how much variance we're willing to accept,
that's risk tolerance.
So I'm going with level of risk
the organization is willing to accept
in pursuit of its mission and objectives.
Agree?
Let's check.
And that's correct.
Okay, we are gonna complete the sentence
by dragging and dropping the terms.
So let me read you the sentence,
and we'll look at the available terms.
Key risk indicators, KRIs, are blank of blank events
that can adversely impact an organization.
A blank looks forward at future outcomes and events,
and a blank looks back at what happened.
So we've got favorable, key performance indicators,
predictors, lagging indicator, unfavorable,
and leading indicator.
So key risk indicators are blank of blank events
that can adversely impact an organization.
A blank looks forward at future outcomes and events,
and a blank looks back at what happened.
What do you wanna do?
Go ahead and put me on pause while you choose.
Well, key risk indicators by their very definition
are going to be predictors of unfavorable events
that can adversely impact an organization.
Now we have a blank looks forward and a blank looks back.
So what looks forward and what looks back?
A leading indicator is gonna look forward
at future outcomes and events.
So what's gonna look back?
That's gonna be a lagging indicator
looks back at what happens.
So key risk indicators, KRIs,
are predictors of unfavorable events
that can adversely impact an organization.
A leading indicator looks forward
at future outcome and events.
A lagging indicator looks back at what happened.
You good with it?
Let's check.
And that is correct.
All right, let's move on to question three.
An organization has determined that one day of e-commerce
is worth $10,000,
and if one server on the server farm failed,
the ability to service customers would degrade 15%.
Now, based on past experience,
they anticipate a failure three times a year.
So what are we gonna do?
We're gonna match the quantitative risk assessment elements.
We're gonna look for SLE, ALE, AV, EF, and ARO.
They told us that one day of e-commerce is worth $10,000.
So e-commerce is our target,
and we happen to be doing it by the day.
So our AV, our asset value is going to be 10,000.
Then what do they tell us?
Well, they tell us that the impact would be 15%, right?
The ability to service customers would degrade 15%.
That's our impact, so that means our EF is going to be 15%.
All right, so let's do our SLE.
SLE is going to be our asset value
times our exposure factor,
so 15% of $10,000.
I believe our SLE is going to be $1,500.
Then they tell us,
well, we can expect this to happen three times a year.
Well, that makes our ARO three,
and what's our ALE formula?
Our ALE formula is gonna be our SLE, which was 1,500,
times our ARO, which is three,
and that gives us an ALE of 4,500.
So in this scenario, our SLE was 1,500, our ALE was 4,500,
our original asset value was 10,000,
our exposure factor was 15%,
and our annualized rate of occurrence was three.
How'd you do?
Do it well?
Awesome.
All right, let's check, and we are correct.
All right, this group is responsible
for determining maximum tolerable downtime, or MTD.
A business unit, an IT department,
an information security department,
or the board of directors.
Who's responsible for determining MTD
for a particular business process?
The business unit, IT, the information security department,
or the board of directors?
I know you know this right away.
Go ahead, and let's just say it.
It is the business unit, right?
MTD, maximum tolerable downtime, not an IT issue.
It is not an information security issue
or cybersecurity issue.
It doesn't go all the way up to the board of directors.
They don't get involved in that minutia.
It is a business unit decision,
so let's check, and that's correct.
All right, question five.
How fast an exposure impacts an organization.
Is that likelihood, the window of opportunity,
the window of vulnerability, or velocity?
This is how fast an exposure will impact an organization.
Likelihood, window of opportunity,
window of vulnerability, or velocity.
Are you ready to choose?
I'm gonna choose velocity
because that's how fast an exposure impacts an organization.
Let's check, and that is correct.
All right, moving on to question six.
The principle that, often, risks are linked,
and failing to address one risk
could cause a chain reaction.
Is this serial risk, regression risk,
cascading risk, or parallel risk?
Now, one of these encompasses two others,
and then one's an outlier.
So this is the principle that risks are linked,
and failing to address one risk
could cause a chain reaction.
Put me on pause if you need to.
This is going to be cascading risk.
That's the idea that risks are often linked,
and if you fail to address one,
it can cause a chain reaction, or cascading.
Now, there are two types of,
or three types, really, of cascading risk.
We have serial risk is a type of cascading risk,
we have parallel risk, which is a type of cascading risk,
and then we have hybrid.
Regression risk is the risk that occurs
whenever we've made a change.
So if we've made a change in system
or a change in code,
making that change could be our regression risk.
Let's double check, and that is correct.
All right, question seven.
Let's match the following risk treatment strategies
with their descriptions.
We have accept, transfer, mitigate, and terminate.
That's down the left hand side.
On the right hand side,
we have acknowledge the risk and continue to monitor,
eliminate the cause or cease the associated activity,
reduce the impact or likelihood
by implementing additional controls or safeguards,
or assign the risk to another party,
generally via insurance.
So go ahead and put me on pause
and match these up then come on back.
All right, let's start with accept.
Oh, it's right there.
I like that.
Acknowledge the risk and continue to monitor.
What about transferring the risk?
Let's see.
Eliminating, reducing.
There it is.
Transfer the risk, assign the risk to another party,
or transfer the risk to another party,
generally via insurance.
And we do this generally when the the likelihood is low
but the impact would be really high.
It's like why you carry personal insurance.
Mitigate, well, it's right there.
We're gonna reduce the impact and/or likelihood
by implementing additional controls and safeguards.
And termination's ready to match as well.
Eliminate the cause or cease the associated activity.
So accept is to acknowledge the risk
and continue to monitor it.
Transfer is to assign the risk to another party,
generally via insurance.
Mitigate is to reduce the impact and/or likelihood
by implementing additional controls or safeguards,
and terminate is to either eliminate the cause,
generally very hard to do, or cease the associated activity.
And great, let's check, and we're good.
All right, question eight.
A business unit has determined that their application
has a maximum tolerable downtime, MTD, of two hours.
Which statement below supports this requirement?
So the word here is support.
Not expresses this requirement,
but supports this requirement.
MTO equals two, RPO is less than two,
RTO is less than two, or RTO equals two.
So the business unit says they have an MTD of two,
so MTD would equal two.
Which statement is gonna help them achieve that?
MTO equals two, RPO is less than two,
RTO is less than two, or RTO equals two.
What do you think?
Put me on pause if you wanna think about it.
All right, well, MTO equals two
is really just the same as saying MTD equals two,
because MTO and MTD are interchangeable,
so that doesn't really support the requirement.
RPO, recovery point objective, is all about data, right?
So we're not learning anything here in this scenario
about their data loss or data requirements.
RTO less than two, that's a recovery time objective.
Probably a pretty good answer.
Let's look at all of them, though.
RTO equals two.
No, we don't want it be equal to our MTD.
We always wanna be less than our MTD.
So I'm going with our recovery time objective
is less than two,
and that would support the requirement
that our maximum tolerable downtime is two hours.
Let's check, and that's correct.
All right, question nine.
We again are gonna have to drag and drop some terms here.
We're gonna drag and drop the risk-related terms
to the correct place.
So let's read the whole thing first.
It's not always possible to avoid transfer
or mitigate a risk to an acceptable level.
A blank is a formal acknowledgement
that a risk has been identified,
but it's not feasible or practical
to implement risk treatment.
Now, the process of approving an exception
on either a temporary or permanent basis
is known as a blank.
A blank is a formal decision not to address a risk at all,
generally implemented
when the treatment cost and risk are disproportionate.
I even got an embedded hint in there.
All right, so we got three blanks to fill in.
Our options are risk assessment, exception handling,
risk treatment, risk exemption,
risk management, or risk exception.
So a blank is a formal acknowledgement
that a risk has been identified,
but is not feasible or practical to implement.
Risk exception is gonna be a formal acknowledgement
that a risk has been identified
and it's not feasible or practical
to implement a risk treatment.
So the process of approving an exception
on either a temporary or permanent basis
is gonna be known as exception handling.
A blank is a formal decision not to address the risk at all,
generally implemented
when the treatment costs and the risk are disproportionate,
and that's going to be a risk exemption.
That's the formal decision not to address the risk at all.
So let's read the whole thing.
It's not always possible to avoid transfer
or mitigate a risk to an acceptable level.
A risk exception is a formal acknowledgement
that a risk has been identified
but is not feasible or practical
to implement risk treatment.
The process of approving an exception
on either a temporary or permanent basis
is known as exception handling.
And a risk exemption is a formal decision
not to address a risk at all,
generally implemented
when the treatment cost and the risk are disproportionate.
You like it?
You agree?
Let's double check, and we are correct.
And lastly, dynamic, central repository
for all risk-related documentation and tracking.
This is a heatmap, a risk dashboard,
a risk record, or a risk register.
What do you like?
Well, I'm gonna choose a risk register,
because a risk register is a dynamic central repository
for all risk-related documentation and tracking.
Let's check, and it's correct.
Congratulations.
Great job.
10 questions, you did fabulous.
All right, what are we doing next?
Well, we're gonna go into Lesson 25.
We're gonna explain the processes
associated with third-party risk assessment and management.
I'll see you there.