So let's imagine an organization has took the time to identify risk and to analyse risk. According to clause 613 We then move into the need to do risk treatment. And risk treatment is all about choosing risk treatment options. Which we'll have a look at here in just a moment, and also determining which controls we might implement to respond to that risk. And we know that in Annex A, there are a list of 93 security controls that we can choose from. which you're not limited to, remember that. And we will need to state which of these we're going to implement or not in a document called the statement of applicability. That's all part of risk treatment. So we'll certainly run through in just a moment creating a statement of applicability. And also what's important in 613. f. Formulate an information risk security risk treatment plan. Also what's important is point F, obtaining the risk owners approval for the risk treatment plan and the acceptance of residual risk. That's the risk that's going to be left. after the treatment has took place. This is vitally important. This is one that sometimes I have identified as being a problem as an auditor where I've seen very good risk processes but then a disconnect between the process and the risk owner. So I'm always looking to see that the risk owner was involved and ultimately made that final decision. But before we look at the statement of applicability and a risk treatment plan We need to talk generally about the different risk treatment options that exist. So let's imagine an information security risk has been identified and we want to do something about it I'll go through a few different options. Now first one, risk modification. Risk modification means changing the circumstances around a risk. So that might be about implementing controls to reduce vulnerability. So let's say for example I have a network architecture and we identify the way in which the network segregated leaves its vulnerable to the attack. So we propose you know more granular segregation and introducing some kind of firewalling technology. We'd be doing a risk modification. To reduce the vulnerability and the likelihood. Or let's imagine we want to reduce impact. A very simple example of that. Let's think about organizations that use mobile devices like laptops if they do if they apply whole disk encryption to that laptop. It doesn't reduce the likelihood of the laptop being lost or stolen, but it does reduce the potential impact when that happens because we have more of a confidence, that confidential data isn't being disclosed. Both of those would be taking risk modification actions. Now the reason ISO calls it modification rather than reduction is In theory, we could allow risk to go the other way. If we identify, for example, we're spending a lot of time and money on a security control that's keeping a risk really low, you're well be well below the risk tolerance level, it may be a case that We can remove security controls to some degree, allowing an increase of risk, as long as it's managed, to assign that budget, time, etc. , somewhere else. So ISO does leave it as very flexible. hence the term risk modification. Other things an organization could do, risk avoidance, risk avoidance is where we take a decision to deliberately as you as you gathered there, avoid the risk scenario uh either partially or to some degree. So for example, um if we were selling goods online and we were seeing a particular amount of credit card fraud, let's say coming from a particular particular territory, we could take the view to stop taking card payments from that particular territory. Now that might be commercially a bad decision, possibly, but it is a theoretical example at least of risk avoidance Or if we said we will not use a particular type of technology because we're concerned about the risk level, you're taking a risk avoidance step. That's not always practical, but it is an option. Another potentially practical option to deal with risk is what we call risk sharing. In previous guidance and in other books, you might read this as risk transfer. ISO deliberately stopped using the word transfer. Because we're not passing a risk to somebody else. Risk sharing is where two organizations of people might share the burden. So let me try and give an example. Outsourcing is a good example of risk sharing. So let's say we have a particular problem, we share that with a third party, the risk still rests with us. I'll give two sort of worked examples on this. So one, I worked with one organisation that identified that it had quite a number of network security problems. And the organisation openly said, look, we don't have the expertise in-house to address some of this stuff And therefore they took a decision to enter into a partnership with a s a company who would maintain their network equipment for them. And they were very transparent about the vulnerabilities they had. And it was therefore the responsibility of the network service provider. to deal with some of these security vulnerabilities. But it's a shared risk because my client can't just then say, ah well, it's managed by somebody else if there's a security breach, an incident, etc. It would still be my client answering to the regulator, answering to the customer, but they have shared the workload, obviously with due diligence, with that third party. You often see this as well. Another example is with card payments, so websites that take card payment online. Some companies will say, well, rather than us take the risk of processing those credit card details ourselves We'll have a module that's run by a trusted third party, usually a PCI DSS service provider, and we'll share the burden with them. So they're going to deliver the service obviously for a fee, but the risk is shared. Now there may be cases where none of those options are practical or affordable. It could be that the cost of implementing modification is prohibitive or technically not feasible. There might not be a partner you can share it with and maybe risk avoidance just doesn't make sense At this point we might be into the realms of what ISA would call risk retention. That is to say that we have to accept that risk. That doesn't mean accept it forever. We might accept it for a period of time until better options come along. But accepting risk is something that ISO allows, providing that it's done as part of a proper process. in in in line with your risk management process and providing it's not just the default go-to option so we can't just say well uh we've got a long list of risks let's just sign everything off and hope the auditor uh is happy with that But where it makes sense those decisions can be made. But let's talk about risks where the treatment will be to implement controls. So according to clause 8. 3 of ISO 27005, the guidance document on risk management, it says that we shall select controls in order to address risk And those controls can be preventative, detective or corrective in nature. So we mentioned that in uh in the earlier section in the course and the difference between them. But practically speaking, we will find the controls that are very relevant here in annex A of ISO 27001. So let me just mention a couple of things about Annex A. So as we've said earlier, there are 93 security controls in there. It is not mandatory to implement every single one of those controls. An organization will need to run through them and decide which ones are applicable and which are not. Where a control is not applicable, the organization will need to mention this in a document called the Statement of Applicability and basically give a justification. You also need to justify the controls you've included by the way as well are marked as applicable. But when it comes to things that are not applicable, wearing my audit hat, I'll often talk the organization to say, okay, how have you come to the That conclusion. And sometimes it might be that a control isn't needed because the process isn't in place. For example, there are controls in Annex A about software development. Well, if your organization doesn't do software development or it's not in scope of the ISMS, that might make sense to mark that control as not applicable. And we'll have a look at that in a bit more detail in just a moment. But one thing I always like to tell people about Annex A is when you look at those 93 controls and try and read them, they're often described in no more than a sentence or a couple of sentences at best. And whilst you know you could read them and they probably make some sense, it doesn't give you a lot of implementation guidance as an organization. Let's take A5. 7 on threat intelligence. It simply says, you know, threat intelligence shall be gathered and processed by the organization or something along those lines. Not with a lot of detail in it. Now let's imagine I'm the implementer here and not the auditor. Then I might want some greater advice and guidance on how I'm going to fulfill that control. Well, that's where ISO 27002 comes in. So what ISO 27002 does is it's a document, a guidance document. It takes all the requirements of Annex A, or all the controls I should say, of Annex A, and for each and every one of those gives an explanation. So let's say let's take A5. 7. It's numbered the same in ISO 27002. You could go to that section and it will explain the control and its purpose or the objectives of such control. control is. It will give some implementation guidance and examples of things to think about and some additional reading what we call supplementary information. Now the key thing is about ISO 27002, it is there to help the implementer. Now as an auditor, I still look at ISO 27002. to make sure I'm familiar with the control, to make sure I'm asking the right questions as an auditor. However, I am not auditing an organization against ISO 2702 because it's not a set of requirements. So I cannot raise a finding to say you've not done something where the word should is used Because the word should is guidance. But at least if I've read it, I understand what the control is about. It puts you in a better position as an auditor to ask the right questions. But as an implementer, I would argue 27,002 is absolutely vital Now, there's a diagram we've included here, this sort of thing that looks a bit like a wheel, if you like. And this is for people who may be familiar or may have worked with the 2013 version of the standard. and want to see the comparison between the Annex there and Annex A in the newer standard, the newest version being the 20th So in the 2013 version of the standard, and some organizations are still aligned to that because they've got till the uh I think the end of uh October in 2024 to try transition so maybe some of us still sort of uh using that. That had in the annex 114 security controls grouped into areas which were called control objectives A5 through A18, covering many topics. And what we've seen in the new version is an effort to simplify that. to put 93 controls into four distinct areas. And people certainly have their opinions on what they prefer, but that's where we are today. And of course, the logical question I get asked is, hang on, we've gone from 114 controls to 93, so surely the newer version of the standard isn't quite as strong. That's not actually true at all because None of the controls from 2013 have been deleted as such. What's happened is in the newer version in 2022 quite a few of those controls have been merged. So in other words, where you had separate controls. describing something that have been brought together. And actually there's new controls in Annex A of the 2022 version. Things like threat intelligence, data loss prevention, data masking and information deletion. and configuration management, web filtering, those are a few that I can name, that have been added. So believe it or not, actually you've now got more control in the annex than you did in the previous version. There are plenty of documents out there that do show a mapping as well available online that if you want to see the mapping between the two annexes So, with all of this in mind, we need to create a document called a statement of applicability. As a when I say we need to create it, the organisation implementing the ISMS needs to to create it. We as auditors will of course review it. And as I've said, this SOA statement of applicability is a document that lists all 93 controls And the organization will state whether they apply or not. If they do, why? If they don't, why not? Usually if they do, though the answer to that will be to address risk, to address a legal or regulatory requirement. fulfill the customer requirement. Our job as auditors is to review that SOA and make sure, as we'll see in a second, that those controls and those selections are justified. If an organization decides it's going to add other controls into its ISMS, so let's say we have a company that needs to follow PCI DSS because it's processing credit card data and they include those controls, those controls should also be spoken about in the statement of applicability. So let's just explore that a little bit further. Let's imagine you're looking at a statement of applicability and an organization has marked some controls as applicable. So they've said yes, they need it We need to see the justification. Why does it apply? So they can't just say, yes, because you know we're just ticking a box. There's got to be a reason. So let's take this uh example on the slide here, uh which is related to A5. 20. Relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship. And they've said They want to implement this control because they want to ensure security across all IT components. A number of IT components are being used or delivered by suppliers. This is perfectly fine justification. As I say, they could have said we've identified a risk in this area and therefore we need this control to address risk X, Y, and Z. They could have said we have a legal and regulatory obligation to monitor our supply chain, therefore the supplies, or we have a customer uh requirement in our contract if that was applicable. So there's many ways there, depending on what the right answer is, to justify it. But they've given an explainer. Note that that explainer is only a paragraph. We don't need as I like to say to people, war and peace in here. You can show me other more detailed technical documents separately, but just enough of a summary would be sufficient On the flip side, excluding a control, we've got a few examples here, of A6. 1, an organization deciding not to implement that because it violates legal or contractual requirements. Now in reality it's probably a partial uh answer to that because I'm sure there's still some background checking they could do. But anyway, if a control was at odds with a law or a regulation We could exclude it. Or if it's just not relevant, like remote working, if we don't actually have people working remotely or software development if we're not doing that in-house, those are perfectly sensible reasons to exclude exclude controls. As an auditor our job is really to look at especially those excluded controls make sure the organization has fully understood them and fully their their reasoning makes sense So here we have a simple example of a statement of applicability. Obviously, there's only two controls in it, a real one would have 93. And this is just to show typically how an SOA is laid out So you can see in here two controls. One is marked as applicable, yes, with a description and a justification. And then we have the one there on remote working, applicable no. justification. One thing to say is this is a living breathing document. The organization should always be adjusting and updating its statement of application. Is necessary. And the last thing to say about a statement of applicability is when an organization is certified on their certificate, it will refer to the statement of applicability version and anybody who's looking at the certificate is entitled to ask to see a version of the SOA. In other words, if I'm doing due diligence on an organization and they tell me they're certified to ISO 27001 as well as understanding the scope of the ISMS, I would want to know which controls they've implemented and which ones they haven't. And it would be perfectly reasonable to ask that question. The last part of clause six is also worth mentioning here as well, is not so much about risk, but objectives. It says the title of it is the information security objectives and planning to achieve them. So all organizations should have information security objectives. Some of those objectives might be derived from the risk assessment we've done, hence why 6. 2 for that. 6. 1. Some objectives may be derived from commercial objectives, you know, things we want to achieve. But of course the whole point of having an ISMS is to fulfill certain objectives. just have an ISMS for the sake of having one. And what the standard says here is the information security objectives that the organization does identify shall, as we see, be consistent with the information security policy. which would make sense, be measurable, if practicable, I'll come back to that in a second. Take into account applicable information security requirements. and results from the risk assessment which we've just been talking about and those objectives shall be communicated and updated as appropriate. So what this means Is depending on the work you've done in clause four, understanding the needs and expectations of interested parties Depending on the work we've done in clause 6. 1, understanding our risk, depending on the discussions we've had with our management, we'd put together a set of objectives Now some security objectives might be very high level, you know, basically long-term. You know, you might say an organization might say they have an objective to ensure ongoing legal and regulatory compliance, for example. But some may have shorter term, much more measurable objectives. So if you said, well, based on our understanding, we want to improve our security incident management response time by X percent in the next 12 months. That would be a very clear short-term objective. But what we're looking for is not that the organization just has a list of objectives, but are there clear plans that really specify how they will achieve them. Because in the end, from an audit point of view, the judgment we're making is not only Does this ISMS conform to the requirements of the standard? The other big one is does this ISMS allow the organisation to achieve its objectives? Because that's the whole thing. purpose so of course they can only achieve it with adequate plans in place.