Let's take a look at the next clause, clause eight operation. And that has three parts to it, operational planning and control, information security risk assessment, and information security risk treatment. So let's have a look at operational planning and controls. So what this is about in clause 8. 1 is we've said that when we establish an ISMS we'll implement security controls from Annex A and various processes. But of course an organization should think very carefully about how to roll out those controls and processes so that when they are implemented, they're implemented effectively in what I would call a sustainable manner. In other words, they're there to last. speak. So this means thinking through how those processes will be defined by having clear criteria to say this is what what success looks like and having a level of planning. So for example, let's imagine an organization was going to deploy, let's say, a log management solution to monitor and that they're going to use to capture logs, maybe monitor for suspension. Well what you'd expect is there'd be a series of um series of things done. The organization would specify the need for such a lock management. management system, you know what sort of functionality should it have, what sort of events and logs should it capture, what sort of capacity it should have, all of these things. It would specify some criteria before actually making that decision. The organization would specify how that's going to be used, you know, what's the processes to be followed to review those logs. how does that process link to the incident management process of the organisation and so on. They'd probably want to think about the resource requirements to operate that control effectively. Do they need a dedicated member of staff or a team. They might want to think about whether there's any training requirements that are needed before it's rolled out. how that might be communicated to the wider organization. So there'd be all these things essentially thought about before the deployment. And that's what we mean by operational planning and control. So that we have a confidence that what we roll out is going to be effective. Now there is an interesting point in here as well, which says that the organisation shall ensure that externally provided processes, products and services that are relevant to the ISMS are controlled. What this means is is if the organisation is depending on let's say a service provider or some some um process from the outside that this is still managed. So for example if we said right we're going to use a a SaaS platform, a software as a service platform to let's say for let's say for risk management. Well we're not just going to just buy the platform and just start using it even if we argue that the the actual tool is provided by a SAS provider We as the purchaser of that, the implementer of ISO 27001, would still need to make sure that that service provider meets our requirements you know offers the functionality that's required, offers the level of service, maybe availability, the level of security that's required. And it would still be part of the ISMS to monitor the activities of those kind of service providers or outsourcers. There is a separate ISO standard document that might help here which is not security specific but it does look on look at um outsourcing and it's called ISO 37500 it's called guidance on outsourcing Certainly isn't a requirement to look at that for this particular aspect, but it might help in giving you some guidance on how to have proper governance and oversight of um organizations like service providers and outsourcers. So that's what 8. 1 is speaking about. Now you might when you've looked at the beginning of this section have thought, what's this about information security assessment and risk treatment? Surely we've already spoken about that and looked at it in clause six And that's true. And this isn't telling us to do anything different, but essentially what we're arguing is you implement your risk management processes as per clause six. essentially 612 and 613 and then you in clause 8 the do phase of the plan due checkup cycle you execute those things So that this is confirming that those risk assessments are actually being carried out, that the risk treatment plans are actually being implemented. So essentially you're moving from the plan stage of risk assessment and treatment in six to the actually doing it in cloud. So there's nothing different here other than we have to execute the stuff we plan to execute in clause six. And that then feeds into implementing controls and planning them properly, which is what 8. 1 is talking about Now when we think about an ISMS and going through a series of steps, at some point when we've implemented controls, the organization needs to be checking whether those controls work effectively. And that's what clause nine tackles. Clause 9 is performance evaluation broken down into three areas, the monitoring, measurement, analysis and evaluation, basically metrics. Internal audit and management review. So let's just have a look at those and what they mean and some of the key points. So clause 9. 1 talks about this concept of monitoring, measurement, analysis and evaluation. What that means in a practical sense is deciding what parts of the ISMS the organization would like to monitor on a regular basis in order to identify its performance essentially and to evaluate performance. Now the ISO standard itself does not say which controls or which processes to monitor and what performance evaluation targets to have So what we typically say here that's up to the organisation to select. But the important point is we don't expect an organization to take clauses 4 to 10 and take every control in the annex and try and have a measurement or performance evaluation for everyone. Instead we expect them to focus on key things. And the big one for me would be security objectives. So an organization should be looking at what security objectives it has and then asking the question how will it measure and check whether those objectives are being fulfilled. That's the primary priority here. Other things an organization might want to measure regularly might be things like legal and regulatory compliance. It might be about measuring controls that are implemented to deal with significant risks. Because obviously if those controls aren't working as expected, then risk may be higher than it should be. And what we want to see is not just a list of things that will be measured, but some information on how frequently those measurements will take place. um how practical they are, you know, who's doing it and so forth and what action is going to be taken in response. Now when it comes to performance evaluation, in other words deciding based on these measures what good looks like. The ISO standard doesn't say this to us. So it doesn't say, for example, with patch latency, how long it takes to apply patches that we shall do that in five days or ten days or something like that. The organisation will set its own targets. Those targets might come from contractual obligations, legal obligations. obligations and other standards or it might come through its own setting its own KPIs. So what we're looking at when I say KPIs key performance indicators when an organization designs and implements an ISMS it will want to identify early on what those key performance indicators are. From an audit point of view we want to make sure that the organisation is checking those things regularly. Now the other thing an organization should be doing to validate whether its ISMS is working effectively is to be conducting its own internal audits. So when we deliver this course, we're talking about this from an external auditor's perspective. That being said, everything we teach in this course can be applied by people who are doing internal audits as well. So if you're an internal auditor Everything you learn here you can still apply. But basically the standard requires that internal audits are performed at what it says regular intervals And the purpose of internal audits is to validate whether the ISMS meets the requirements of ISO 27001, but also to validate whether the ISMS is actually effectively implemented, maintained, is it set up in a way to help the organisation fulfil its objectives and so forth. Now there's a few points to make about internal audit that are important. As we'll describe in audit principles Independence is a very important part of audit. Now, internal auditors aren't necessarily independent of the organisation, but they still need to be independent of the work they're assessing. So we need to make sure that whoever's working as an internal auditor is not auditing areas under their control. They're not essentially auditing their own work. We need to make sure those auditors are in a position wherever they sit in the organization. to be able to openly make honest observations based on the evidence that they see. We also want to validate that internal auditors have the necessary competence We mentioned competence in clause 7. 2. We will go through a little bit later on the specific competence requirements for auditors. We need to make sure the internal auditors have those skills to perform them. And we also need to make sure that the organisation doesn't just do a one-off audit, but they have what we call an audit programme in place. An audit programme means there'll be a series of audits over a period of time. In some organizations, rather than doing sort of one ISO 27001 internal audit every year, they might spread that work out over a period of time, perhaps doing deeper dive audits into particularly critical areas. A quick example is I work with a software as a service provider who they have quite a unique product. They develop all the software themselves and therefore one of the critical areas is secure software development. So their internal audit programme includes many reviews of software development practices, possibly more reviews in that area than others because they see that as a critical area to be more closely monitored. So some of those audits focus regularly on that as part of a bigger audit program. And then in clause 9 we also have what's called the management review. So the management review is the opportunity for top management, which we talked about earlier on. It's their opportunity to see what is happening with the management system. So a management review does not have to be a meeting called management review, although that can happen that way, but at regular intervals top management need to get together, whether it's physically, online, or wherever it might be. to take a look at the management system. Now usually this would be facilitated by a security manager or a CISA or whoever's sort of overseeing the ISMS And in management review, it's important to point out is usually looking at strategic aspects. In other words, does the management system meet the requirements of the organisation? Is it aligned to objectives? Does the scope of the management system need to change in any way? Does it need to be updated to respond to risk or legal and regulatory requirements? And some people ask, well, what should be on the agenda in these management reviews? You know, what should we talk about and what should we cover? Well the answer to that is I don't need to give you an agenda because you've actually got it here as you can see on the slide, A through G, the management review shall include consideration of all of these points. Whenever I conduct an audit we always comment on whether all of those points have been covered. The point about a management review though is it's not just a meeting where these things get discussed. It is a place where decisions can be made about how we continue to operate the ISMS going forward. So management review should be an effective program for top management to have an influence and an oversight of the management system Now, given that those three things we've talked about are all to do with checking how well the management system is actually working. Clause 10 then is focused on what we do in response to those things or what the organization does in response to those things. So there are two things in clause 10. 10. 1, continual improvement. and 10. 2 non-conformity and corrective action. So if we talk generally about continual improvement, 10. 1 This is one of the requirements which basically has a one, well almost like a one-paragraph requirement, which basically says the organization shall continually improve the suitability, adequacy and effectiveness of the ISMS. That's literally all it says. So suitability, is the ISMS fit for purpose? Adequacy, is it meeting the minimum requirements that need to be met by the organisation? and effectiveness, is it working to the organization's needs? So the issue with this as an auditor is you might ask well how do you even check this? And there's two things. If this is an initial audit, that is to say this is the first time we've ever been to see the organisation and the ISMS implementation is relatively new. There might not be lots of different improvements that the organisation can point at to prove this is in place, but what they could point at is how they're going to measure and what mechanisms they've got in place to respond. As an example, I did a recent audit. and the chief information security officer showed me an analysis that the organisation had done. So they took all these areas of security, they called them capability areas, like incident management, education and awareness, risk management. and so on. And for each area that identified where they currently were in terms of maturity. And basically the seesaw had set. a strategy for the year ahead saying these are the improvements we expect to see and every month they were checking their metrics to see are they on the right track So even if not everything is in place that they want to have in place, they're demonstrating a culture of continual improvement. Over time, when an organisation gets certified, of course, every year, as we'll get to, we do what's called surveillance audits, and in a surveillance audit we're always looking for examples of continual improvement. Now this is slightly different to clause 10. 2, non-conformity and corrective action. So in brief in non-conformity is the non-fulfilment of a requirement. So in other words when a requirement of the standard or requirement of the organisation's own requirements is not being met and the organisation know that it's not being met, whether they've detected that through metrics an incident or through the audit process, clause 10. 2 requires that action is taken to address it and to prevent a recurrence in this case. So this is where we just need to quickly draw a distinction between a correction and a corrective action. Both of them are important but they're both slightly different. And this is an audit example I can give. So I did an audit of an organization and we found that on their network there were a number of devices that had not had their software patches applied for over 12 months. And the organization openly said, look, this is an oversight, this is a mistake. So it wasn't a risk-based decision. They basically had a number of flaws and problems. And they said, ah, well what we'll do immediately is we'll apply all the missing patches. will pretty much do that straight away. Now that's obviously a good thing. I'm not going to discourage that. That's what we call a correction. They're taking action to address the symptoms of a particular problem. But the question is, what gave rise to these machines having missing patches for over 12 months in the first place? And what's the chances when I come back in three, six, twelve months time, that I'm going to find the same problem again? So they need to do some kind of root cause analysis to get to the bottom of it and then take action to prevent the recurrence. And in their case, they'd found a number of problems with their process. They'd update in response they updated their patch management process. They did a lot more close monitoring. They made somebody particularly responsible for that process. And eventually that addressed the problem and stopped it recurring. And what we've described in the latter part of that example is a corrective action plan And that's what this slide here is showing you with the steps involved in a corrective action process. So in any case where a non-conformity is detected. We would expect an organization to describe that non-conformity, conduct a root cause analysis, maybe they've got a root cause analysis process. An organization I spoke to recently about this demonstrated an example to me called the five wise analysis which basically asks you to as it says look at a problem through multiple angles and at least five times ask each uh for each answer to each question we keep asking why until we get to a root cause. An organization needs to evaluate and select solutions to that problem but and then implement them, but not just implement the solution and assume it's worked. they will monitor for a period of time has that action worked. So like that organization I was just telling you about with their patch management, they didn't just rewrite the process and say, well, let's close the non conformity, they monitored that for a period of time and over several months they could see that they were no we were no longer falling behind on their patch management cycles So in summary what we've tried to do in this section is give you sort of an overview of an ISMS. by doing a bit of a helicopter tour of clauses 4 to 10. All of those are worthy of much more discussion and please be assured we will be digging into some of these a lot more as we go through here But all of clauses 4 to 10 are mandatory in order to achieve ISO 2701 certification Based on risk, an organization will then choose which controls from Annex A to implement as well, and they can decide which are applicable and which are not. And ultimately at the heart of ISO 27001 is risk management. So what I would say is the part clause six where we talk about Identifying, analysing, evaluating and treating risk is fundamental because that then influences everything else that we see in clauses four to ten.