Let's have a look at the next clause in the standard, clause six planning. Now this is broken down into three particular parts, the actions to address risks and opportunities, information security objectives and planning to achieve them planning of changes. So let's start on this first one, actions to address risks and opportunities. We see this in clause 6. 1. 1 and something I want to really draw your attention to here because often there's a little bit of confusion about this. 6. 1. 1 isn't specifically about information security risk We'll come to that shortly. It's about something slightly different. So let's just have a look at the words and then I'll try and explain my point here. So what we see is the following that when planning for the ISMS that the organisation shall consider the issues referred to in 4. 1 and the requirements referred to in 4. 2. So remember that's context of the organisation, the needs and expectations of interest. parties and then it says and determine the risks and opportunities that need to be addressed to ensure the ISMS can achieve its intended outcomes prevent or reduce undesired effects and achieve continual improvement. So what's this speaking about? This isn't necessarily speaking about identifying information security risks to particular systems or particular information. This is about risks to the ISMS itself. So let me try and explain this. So let's think about a project. Any project for that matter. You imagine a project manager would usually do a risk assessment. When they're doing a risk assessment, they're not focusing on security or any other matter. What they're focusing on is what's the risk of the project failing You know, could the project overrun? Could it uh go over budget? Could it completely fail to deliver? Well this is a similar story here. What we're looking at is when we're thinking about establishing an ISMS, are there any situations, risks, etc. that could affect the ability of the ISMS to work as expected. ? So for example, if we identified that we had a resource shortage, that would be a risk to the ISMS itself. There might be a chance that the ISMS cannot fulfil its objectives. If we didn't have appropriate support from management, we'd have a risk to the ISMS. On the flip side, an opportunity is indeed the chance to potentially improve something or or uh gain some benefit. So the opportunity of establishing an ISMS could be it could open the doors to more commercial opportunities for example Or one of the opportunities in an ISMS could be that we're going to conduct detailed risk analysis and we'll identify opportunities to drive efficiency in certain processes or remove duplication, etc. So 6. 1. 1 wants us to focus on those particular risks and opportunities. Now that doesn't mean that we're going to ignore information security risk. quite the opposite. That's why there's a separate clause on that, clause 612. And clause 612, and I won't read it all out line by line, again I'll just give you the sort of summary. The organization shall define and apply an information security risk assessment process that does a number of things. The first one establishes and maintains information security risk criteria. Information security risk criteria, think of criteria as rules, are the rules we're going to use to understand our risk. So for example, we might lay out things like risk acceptance criteria. That is to say when a risk is identified, how do we decide? whether or not that's acceptable to the organisation. Now we might have an answer to that because the organisation may already have some general rules or criteria. And the criteria for performing those risk assessments, so when do we need to perform an information security risk assessment Is it at the start of a new project, during a project? Do we trigger an at risk assessment again if we have some kind of incident? Do we do them every so often? These are the questions that will answer in a documented risk assessment process. We then talk about the fact that it should ensure repeatable results. I'll get into that a little bit later in this section where we talk about having a proper risk assessment. assessment method and then we will do a number of things including identifying information security risks and something I want to draw your attention to right now which I think is important right at the start identifying risk owners so risk owners are individuals in the organization who have a let's say a level of authority, a level of trust to make risk decisions. It's very important that we know who those risk owners are early on. Because when we start to identify risks, we're going to have to consult with those owners to make decisions on what we're going to do with risks. If we don't have risk owners, then the process could come grinding to a halt. So this is an important uh point that the standard. that is calling out. And in a risk assessment, as we'll see in just a moment, we have three stages in a risk assessment, the risk identification, analysis and evaluation. So we expect to see according to clause 612 a very clearly defined, understandable risk assessment process. So as an auditor, when I'm coming in to look at this, I'll be looking at is the process defined, and then I'll be looking at evidence by getting somebody to maybe take me through risk assessments. that have been performed. But let's talk about some important factors then about a risk assessment approach. So there are three sort of things to cover off here which you can see in mentioned in the slide. here that we need to identify a methodology. So let me explain this very clearly. So clause 612 tells us what should be considered when doing risk assessment It does not tell us how to conduct a risk assessment. It doesn't say you shall calculate your risks on a scale of 1 to 10 or high, medium, and low, or using some other kind of formula. Nor does the guidance document, I suppose. 2705. What does that is what we call a methodology and I'll talk in a moment a little bit more about methodologies, but we need to have an agreed way of conducting those risk assessments As well as having an agreed way to conduct those assessments, we must have predefined risk acceptance criteria. So let me give you an example. I was working with an organization. I spent that they didn't have such a process in place. We were trying to get this set up. I spent some time with the finance director. And we started to come up with some ways we could calculate risk. So we had what's called an impact table. So we had five levels of impact. So when we're calculating the damage that could be done, we could place it on a scale. And I sat with the finance director and I remember him pointing out a particular number on this scale and he basically said to me If as part of these risk assessments we identify any risk that could result in the loss of this amount of money, and he mentioned a specific figure, or more And the likelihood of that happening is medium or above, that cannot be accepted by the Information Security Committee. This needs to come to the board for review So in this case he's given me, involuntarily you might say, some criteria, in this case risk escalation criteria. And these are the kind of conversations that an organization should be having to define this. And an organization should be identifying the overall level of acceptable risk. When it comes to information security. Now ultimately that is set by top management. And the level of acceptable risk will vary, of course, depending on organisation. And sometimes when we talk about risk, we talk about this concept of risk appetite. And risk appetite is the amount of risk that senior management or directors or or company owners are willing to take in certain circumstances. That might influence the answer here. So for example, I've worked in organizations that have very different risk appetites. So I've worked in um Your government entities that might have a low risk appetite because they are looking for stability. They don't want to take unnecessary risk Whereas if you go into say a venture capitalist organization that's looking for rapid growth, they might have a much higher risk appetite because indeed that's That's what they're doing. They want to innovate and take risks, but not reckless risks, but risks to grow. And again, as an auditor It's not for me to say what is right or wrong here or to enforce my preferences on the organisation but I do want to understand have they defined these things and why and does it have the appropriate support from top management. Now there is a note here which says the following. The organisation must ensure that the risk assessment generates comparable and reproducible results. So how does an organization ensure comparable and reproducible results and what does that actually mean? Well what it basically means is let's say that there's two of us doing risk assessments for an organization and I come along and do some and you know you come along and do another one that we both approach the problem in the same way and that means basically we should have a defined methodology And there are a few things an organization should think about when they're choosing a risk assessment methodology. Now the first thing I would say here is there are many methodologies available for assessing information security risk. Some of them very simple, some of them very, very detail-oriented and extremely complicated. It's also possible to design your own methodology. So ISO doesn't dictate what methodology to use. So how can an organisation settle on one that makes sense? Well there are a few things that the organisation should think about. The first, compatibility with the requirements of 27001, that's relatively easy because basically as long as the methodology considers threat and vulnerability impact and likelihood and the three tenants of security pretty much that that that part's answered straight away so as long as your method does those three things that's point number one So what else might an organisation want to take into account when thinking about this? Well other things that are important, vocabulary of the method, in other words, the way it's written Does the language make sense? I don't mean language as is as in is it in English or French or German? What I mean is um does the terminology make sense? So if it refers to the concept of threat, for example Do we understand the work that word in the same way? So when we get output from these assessments, will it be understandable Now I'm not going to go 1, 2, 3, 4, 5, 6, 7 here, because actually for me the next one, which I want to talk about, number 5 on here, ease and use and pragmatism of the method. Let me explain what I'm saying here So there are some methods that are extremely rigorous and extremely complex and are really good for deep dive risk assessment. So I can think, for example, spending time in government departments, there are some methods we would use and one risk assessment of one information system could take 50 days or more because we're really looking under the hood at a lot of technical detail, but in that circumstance that's justified because of the type of systems and information we're trying to protect But that wouldn't necessarily be very useful if I took that method and tried to apply that in a small sort of startup company or commercial business It it it would be rigorous, yes, but it probably wouldn't be practical. So this is not me, I'm not trying to argue that we don't need to be rigorous. What I'm trying to say is we set up a method that is suitable for the organisation at that time. An example I can give, I worked with a very small organisation not too long ago. They had nothing in place for this at the time. They weren't overly familiar with this idea, so they didn't it's not like they had a team of risk professionals in the organization. So we started with something simple. We actually built an Excel spreadsheet with some very simple to use steps. Now is that the end game? Is that where I want them to be long term? Of course it isn't. We can get more sophisticated and we will over time as the organization matures. So let's make sure we pick something that's fit for purpose. Now if we are using a relatively complicated method, then there might be good questions in points three and four. Is there any software that the organisation can use to aid their risk assessments. The only caveat I would give to that point is that software tools are only as good as the person operating them So you can have the best security tools available, but the person using it still needs to be familiar with the method to be able to explain the output. And that also speaks to point four. If we're going to select a method, are we selecting one that's well used, that other organizations use? that's properly documented where we can get training or professional support if we need it rather than something that's a little bit more obscure for example. And we can also think, last couple of points, about cost to utilisation. That's very similar with ease and pragmatism. You know, how much time does it take to conduct this risk assessment? Do you need to bring in a specialist to do it, etc. We want to get that balance right. So all of these things can help. And whilst I don't promote any particular risk assessment method, just to maybe point you in a direction a little bit, there are methods out there you can think about So some that I've seen in this space are things like Octave, for example, from Carnegie Mellon University. There is actually Octave S and Allegro that's targeted at smaller organizations, things like um IRAM from the Information Security Forum is a really good example of a risk assessment methodology, platforms like VS Risk or a Rambuffer, etc. None of these are me promoting anything in particular, but just some examples that might help you to start looking and thinking about risk assessment methodologies. But there are plenty out there if you do that research But all risk assessment methodologies, regardless of how complex or not they are, go through a series of stages and they should follow the stages that are laid out in ISO 20 the guidance document that is there to support conformity with these particular clauses. So the first risk identification So risk identification is the step of identifying risk scenarios. This is not about likelihood and impact, this is about simply identifying potential scenarios, working with risk owners and other experts in the organization to see what risks might be relevant And there are typically two ways we can set about identifying risk in an organization. Now, firstly I would say this is never done by one individual on their own. Often it's a collection of people. From a given part of the organization. So you might have a facilitator, a risk expert, but then other experts who can contribute. And we can do either an event-based or asset-based approach or both. But let's say an event-based risk assessment. or risk identification I should say is where we talk about specific events in general. So let's say for example ransomware we could have a general discussion about the risk related to ransomware in our organization and think about that event and think about how that event might play out. That's quite a generalized thing. But an asset-based approach is where we take the asset, we look at the asset and we look at potential vulnerabilities and threats. So let's say one of the assets is a CRM system So in an asset-based risk assessment, we'd take that CRM system, we would look at the design, the build, all the details we can, and then we'd say, okay, does this system have any vulnerabilities? What do they look like? How could they be exploited? And from that, we would identify a set of risks that would be quite specific to that asset. So an event-based approach gives you a good organizational overview, but then the asset-based very specific. So let's take the ransomware example. Let's say we look at ransomware in general Hitting the organization. And then when we do our asset-based assessment, we can say, okay, how would that ransomware scenario play out for this system system because it might play out differently in one environment to how it does in another. So for me, if you want to be really rigorous, I would say both approaches probably need to be done hand in hand. Now again I caveat that with that depends on the um importance of the assets, the level of rigor you need to go to. ISO 27001 does not demand this, but I think if you want to do risk assessment, or risk identification rather well, a combination of the two approaches would be really helpful. Now one of the things that sometimes I found comes up in risk identification workshops, for example are people saying things like, uh well that scenario is uh never going to happen, so we shouldn't really talk about it, and things like this. And I always argue in risk identification Let's not have that argument now, let's have that argument in the next phase. And that next phase is risk analysis and evaluation. So risk analysis is where we can have that debate, because what do we do in risk analysis? That's where we look at the potential consequences if this scenario played out and the likelihood And there are multiple ways of doing this. Likelihood can be arrived at by looking at events and how frequently they might occur. It can be worked out potentially by looking at previous historical events, if not in our organization but in others. But with the absence of that information, let's go back to the conversation we had in the previous section about threat and vulnerability. And the way I think about it is if you've got an environment that has vulnerabilities The question is, how easy are those vulnerabilities to exploit? So some vulnerabilities will be very trivial to exploit. Some will require possibly a lot of uh insider knowledge, a lot of expertise, a lot of determination and motivation to exploit. And then you ask yourself the question Well how motivated and capable are our threat sources? If you've done your threat analysis properly, you can answer this question. So logically speaking If I've got vulnerabilities that are easy to exploit and highly motivated and capable threat sources, logic would tell you that the likelihood of that risk playing out is probably a lot higher than the opposite way around. If I've got a vulnerability which yes could be exploited but requires hours of effort insider knowledge and various other things And I'm not facing sophisticated threats, let's say, from foreign intelligence services or organized crime groups. It might be a less of a likelihood Now again there's a lot more we can say about that, but for now what I'm looking for from an audit point of view is does the organization calculate likelihoods and consequences and does it have a proper system for doing so And risk evaluation is then taking those things, determining the level of risk, so usually by looking at a combination of the likelihood and consequence. And then making a decision about prioritization, and that often happens by looking at the results of the risk analysis Looking at the risk criteria, the risk criteria are the rules we use to prioritize, a bit like the finance director example I gave earlier, you know This is a level where something needs to be escalated, for example, and then prioritizing risks and deciding which ones might need treatment. and treatment comes where we decide that risks are unacceptable and action needs to be taken. And that decision should be being made by the risk owner. And as we'll see shortly, the risk owner is the one who should be approving the risk treatment plan and validating that risk treatment is taking place.