7 hours 52 minutes
Lesson 4.9 point three
Actions to address risks and opportunities
Close 6.1 point three Information Security risk treatments
In this video, we're going to cover the risk treatment methods,
and we'll also have a look at the mandatory documentation for this clause.
Generally, there are four main types of risk treatment options
in the risk evaluation section. We spoke quite a bit about risk acceptance. This is the first method of risk treatment.
You accept a risk
when a risk is at a level
that falls within your acceptable risk tolerance levels.
if your organization has established that it will accept all risks under a Level two,
as well as risks
that will not exceed
a 10% off the
replacement acid cost to fix
Thesiger treatment option is mitigate.
This is one of the most common
risk treatment options,
as this generally involves the implementation, off controls
or the improvement of existing controls.
You can have one or multiple controls to mitigate a risk.
Mitigating the risk seeks to either reduce the likelihood off the risk occurring
or reduce the impact off the risk occurring
or reduced. Both the likelihood and the impact of the risk occurring.
The next treatment option
is to avoid the risk.
This means that whatever activity is associate ID with that risk or would give rise to the risk
that would be stopped entirely,
meaning it is too risky to use a cloud service provider, for example. So therefore, we won't use a cloud service provider. We would rather do everything ourselves and keep all information that we need in house,
not leverage off any external platforms.
The fourth risk treatment option is to transfer a risk.
The most common example of this is to take out insurance.
This does not get rid of the risk.
The risk is still yours. At the end of the day, you cannot transfer the ownership accountability for the risk.
You can only transfer
off the risk. Occurring
insurance would pay you out a compensating fee for a security incident,
which would make it easier for your organization to recover and manage that incident.
Another option in transfer
is to use a specialist third party for a specific service.
you want to perform penetration tests in your organization,
but it is too risky for you to do yourself as you do not have the qualified personal in house.
you will transfer that risk and get a third party in to perform those assessments for you.
This in itself can present different risks, but probably with different scales and ones that would fall within your acceptable
So what is the documentation that is required for close 6.1 point three?
The standard is not prescriptive about what your documentation needs to look like or how it needs to be done. That part is up to you,
but there are a couple of things that are required to be documented in some way off.
The first document that you will have
outlining your controls is the statement of applicability
as discussed previously.
These are all the controls you have deemed relevant and necessary to manage information security within your organization.
It is important that controls which are not applicable to your environment
are explicitly justified as to why they are not applicable
in the same sense. The controls that are applicable should be justified through a reference to your initial risk assessment.
This shows a justification of the controls as each control is associated to a specific risk
and works to mitigate the risk in some way,
strength through effectiveness. Off the control determines how much a risk is mitigated.
That is a determination to be made by your organization. During the initial risk assessment,
I saw a 27,001
recommends using the ISO 27,002
or an extra A
for the controls framework upon which to base your statement of applicability.
You can, of course, use any of the available controls frameworks
such as in a special publication 53.
The ISF standard of good practice privacy laws is a 23 22 3 or one, etcetera.
So why is this statement of applicability required documentation for floor 6.1 point three?
This shows the applicable controls with links to items on the risk register.
It also shows non applicable controls with justification.
The statement of applicability shows
that existing controls have addressed some or other risk in some way off
your risk treatment process. The ways in which you go about treating risks should be documented
as you assign different risk owners that are not necessarily part of your direct I sem s team or even have an information security background
should be equipped with the appropriate knowledge
guidelines of hard to properly treat risks.
This can include the methods that need to be employed. Example controls contact people to work with and so forth.
The risk treatment plan is the key piece of documentation that comes out of 46.1 point three
for every risk that needs to be treated,
specifically requiring a mitigation
or a chance for level of treatment. This would come through into your risk treatment plan.
Risks that have been accepted
should also be documented in the risk treatment plan. But these will obviously require a lot less documentation and if it around them,
the risk treatment plan should contain plans for treating risks within the set due dates.
The plan should also contain the owners or the responsible teams or personal
that will oversee the achievement efforts.
It is also a good thing to include progress updates in the plan
to show that the risk treatment process has been monitored closely
in regular progress updates fit into the plan.
You're probably also generate stand alone reports on your progress.
This will include various metrics to prove that risk treatment is being regularly tracked and acted upon.
This would be presented at somewhat other forum to your top management
for your information security management for him
just to report back on results, and if any support or deviations have occurred,
then this would need to be presented here.
In this video, we covered the full main types of risk treatment actions
and what each one means.
We also looked at the mandatory documentation for risk treatment, as required by the ISO 27,001 standard.