Risk Controls


Risk Management
Risk Management

The course is part of this learning path

Start course

This Course looks at the key aspects of risk management, including risk identification, risk mitigation, and risk controls. We look at the ISO frameworks and the processes you can put in place to manage risks within your organisation.

We then move on to how to assess and identify risks. We look at the difference between qualitative and quantitative risk assessments, as well as considering the guidelines set out by NIST. We move on to look at the main tenants of risk mitigation, which include risk reduction, risk avoidance, risk transfer, and risk retention, before finally looking at the controls you can put in place to counteract risks.

Learning objectives

  • Understand the organisational processes needed to manage risks.
  • Learn how to assess and identify risks.
  • Learn about risk reduction, risk avoidance, risk transfer, risk retention, and risk controls.

Intended audience

This Course is intended for anyone who wants to improve their knowledge of risk management in an information security context.


We recommend taking this Course as part of the IT Security Fundamentals Learning Path.


So, here's our control selection. And if you remember from before, when it comes to dealing with risk, we have the four Ts: treat, transfer, tolerate, and terminate. Now, risks can never be ignored, that's the one thing we can't do, but we do use the term 'avoid', which means that we actually terminate the risk, but we can't ignore it.

So, if we find a risk and we know it's there, it has to go on what's known as our risk register, and then we have to monitor it. That is, we are looking at it on a given date and then we're going to review it once again at a later date. If you don't have that and an auditor comes to audit you for any particular reason, you will fail. So you have to have that control in place.

If you've done a risk assessment and that risk assessment has come up as being there, and then you don't put it on your risk register or you don't have a date for monitoring, you will also fail, and it'll cost you money because you'll have to call the auditors back again.

All right, so, risk can be treated by applying controls, and they can be physical, personnel, procedural, technical.

So, in the security office, we would employ people that are actually trained CIA.

But we train people to use the server, and we train our receptionists how to spot various things, or send them on social engineering training. We can use awareness training for the whole staff; awareness training so they can spot individuals that are in the organizations, spot phishing emails, all that type of stuff that you have to do nowadays to ensure security.

How much of this treatment do we need? Well, to decide that we use the acronym P.A.C.E: pragmatic, appropriate, and cost-effective. So our risk treatment needs to be PACE.

There'll always be some sort of uncertainty, that's just the way life is. But we need to make sure that we can trace our security controls to our actual risks. So, for example, we might ask ourselves why we have a particular control in place and then we can go and look in our risk register and see that oh, it's because of risk number 149 on the register.

So, here we are, we've got intrinsic and extrinsic insurance - essentially internal and external. 

So, here's our intrinsic security assurance. There’s the secure by design lifecycle, change control measures, i.e. putting in usernames and stuff (so that we can actually know who's made changes to the system and when), and then security engagement, which concerns engaging people with security and checking on them.

Then on the extrinsic side, we have vulnerability assessments, so, checking the vulnerabilities, having penetration testing teams come in, putting supply chain controls in place, checking our third parties, auditing them, etc. We need to find a good balance between the two, so that we have a robust security environment.

Here are our threat vulnerabilities. You can see we have attack there - that's the one we've not covered here, the attempt to destroy, expose or to disable, steal or gain unauthorized access, or to make unauthorized use of an asset - that is an attack. So, any one of those is considered an attack.

Ok, so let's take a quick look at vulnerabilites. Vulnerabilities exist in software. They also exist in people, but normally we're talking about software, and these vulnerabilities that exist in software we normally go ahead and get them patched. A lot of these vulnerabilities exist due to poor design, but other causes include poor management of administration, inadequate leadership, poor management practices overall, and poorly architected systems, which could include, for example, information that isn’t encrypted, networks that are using poor protocols, badly put together networks, etc.

About the Author
Learning Paths

Originating from a systems administration/network architecture career, a solid part of his career building networks for educational institutes. With security being a mainstay his implementation he grew a strong passion for everything cyber orientated especially social engineering. The educational experience led to him mentoring young women in IT, helping them to begin a cyber career. He is a recipient of the Cisco global cyber security scholarship. A CCNA Cyber Ops holder and elected for the CCNP Cyber Ops program.