What we're going to do in this section is take a close look at the requirements of ISO 27001. So as an auditor of course we need to be familiar with all of the clauses of the standard and the annex to be able to add. Ask the right questions and conduct our audit. So basically, what we're going to do here is take you through clauses four to ten and also describe a little bit about annex A as well. Now before I start this, I think it's important to point out That we're not as we go through these teaching you to implement these or how to audit these things yet at this stage. We will be getting into how to audit and assess these things. What we're trying to do is just keep you a good broad overview of the requirements. So I like to call this section a bit of a helicopter tour of the standard. So by the time we've sort of finished this you'll have a good idea of some of the points within So let's start off with clause four, context of the organization. So this is broken down into four different subclauses, and essentially it's all about making sure the organization understands itself if you like in order to build an ISMS that's fit for purpose, that's tailored to the needs of the organisation. So when we use the word context, context basically means what is the organization about and from two perspectives, both what we call an internal context and an external context. So for example, an internal context is all about what's happening inside the organisation, such as how is it structured, who makes decisions, you know, what's the governance and oversight look like, what's the capability and maturity of the organisation. Whereas the external context is about what's happening in the outside world. You know, what's the legal and regulatory landscape look like? What part of the world are you operating in? What's the economic landscape look like? What's the demands of your customs, etc. So what we're saying is when we build an ISMS, an organization shouldn't just be building an ISMS out of the blue, but essentially should be taking all of these considerations. into account. And clause 4. 2 sort of expands on that because what it says is that we should understand the needs and expectations of interested parties. So in an ISMS, interested parties can be both internal and external. So external interested parties parties, maybe things like customers, regulators, business partners, suppliers as examples. Internal can be people like senior management. your user base, different teams and departments. And the idea is when an organization builds an ISMS, it should be examining what the needs and requirements of all these different parties are again so it can build an ISMS to respond. So maybe a quick example of that I can give. I remember at one point I worked for a training company that provided services to a government department And there was a requirement, so they were our customer in the contract which said if we discover any compromise of data relating to them, we must report it within four hours of detection 24-7. So that tells us that we need an incident response capability. That's 24-7 that has that response time built into it. ISO doesn't tell us that. but the expectation of our customer does. So we'd need to build the ISMS with that expectation in mind. And we'd also as an organization build an ISMS based on a scope. So One of the things to say is that when an organization puts an ISMS together, they don't necessarily implement it in the entire organization. They can choose which part of the organization it applies to or which business processes are in scope or which particular systems are in scope. And when an organization determines the scope, it should be credible based on the work done in clause 4. 1 and 4. 1 So as an auditor when I'm coming along and talking to an organization and I'm asking them about the scope, it's not so much that I'm there to tell them whether the scope is right or wrong. It's more about have they done the groundwork? Can they logically explain why the scope that they have makes sense? And then we have clause 4. 4 which talks about operating the information security management system. Now in reality, although this is a standalone or it's a subclause, that can only be fulfilled if the ISMS is actually fully established so that all the other clauses and relevant controls are implemented. So as we'll speak about a little bit later, as an auditor, we'll answer the question as to whether 4. 4 is fulfilled after we've looked at some of the other areas. So just elaborating a little bit on the understanding the organization in its context part, so let's think about a typical organisation. An organization, all organisations, whether they're a government agency, a non-profit or a profit-making business, all in the end have a mission, they have a purpose. So a Razondetterie, you might say a reason for existing. And maybe an organization has a mission statement or something like that that we can look at to understand. understand them. All organizations have objectives, things that they're looking to achieve. So if it's a say a a profit-making enterprise they might have objectives over the next X number of uh years for example to expand by a certain amount to launch new products in a new market whatever it might be If it's a non-profit like a government agency, they might have objectives in improving efficiency or improving quality of service or whatever it might be. But the point is organizations should have objectives and most organizations will have strategies. That describes how they are going to reach those objectives over a period of time. So, why is this relevant to a discussion on ISO 2701? Well, let's imagine an organization is implementing ISO 277. 27001, it needs to formulate its information security policy and its objectives. So the last thing it wants to do is create a set of objectives that are contrary to the mission or objectives of the organization. And let me try and give sort of a really good example, I think, of where an organization did this really well. So it was an organization I worked with some time ago. They were an IT service provider. And they'd called us in actually to help them implement an ISMS because they had a contractual duty. There's a contract that they'd won which said you need to have an ISMS and you need to be certified by a certain date. Now as the implementer in this case, not the auditor, as the implementer in this case, we could have easily gone in and just kind of done what we needed to do to get them compliant with that contract, get them certified and leave it there. But early on I had a conversation with some of the directors. I had a good relationship with the finance director at the time and I started asking him about the longer-term objectives of the organization And in that conversation, he kind of revealed that their aim was to start d expanding into the defence sector. They wanted to start selling various services into Ministry of Defence and other defence organizations around the world. And the conversation I had with him based at a very high level went along the lines of, well, in order to be able to achieve that, you're going to need to have a certain security capability. a certain level of maturity to be able to get into that kind of supply chain. Long story short, that led to the formulation of a security strategy which didn't just focus on getting ISO 27001 certified but it focused on building the organization's security capabilities so they were in a position to win business in the defense sector. So what I'm trying to say is we produced a security strategy that was aligned with the strategy of the organization. This is the kind of thing that clause 4. 1 is talking about. We're not building an ISMS just to tick some boxes off for the sake of it. We're trying to build an ISMS so the organisation should be to achieve its longer term objectives. So as an auditor, if I'm wearing my auditor hat, that's what I want to understand when I'm talking to the organisation. What is this delivering for you? When we talk about understanding the needs and expectations of interested parties, as I said a few moments ago, there are many interested parties. that might be affected by an ISMS. There are those who might be directly affected, you know, for example internally, if we start implementing security controls in order to fulfill requirements You know, those that will see that first hand, like users and employees, etc. And then may maybe those who are less affected but are nonetheless interested. You know, somebody like a regulator, for example, might not be seeing your ISMS on a day-to-day basis, but might be So it is a important thing that the organization takes its time to map out its interested parties and to map out what the requirements are. Now in some cases requirements might be explicit. So like the example I gave a little bit earlier on about that training company, it was clearly stated in the contract that we shall report these incidents within four hours of detection. Section. That was non-negotiable. That's a requirement. There may be cases where interested parties don't have a written explicit requirement But a an implied requirement exists nonetheless. So for example, if your organization is selling goods or services to the general public, you might not have a written contract specifying all the security controls you need to have in place. But you'd still say there's an expectation, you know, the members of the public would still have a certain expectation about how you process and store their data, as well as obviously the legal and regulatory aspect. The other thing that's important when an organisation does this is have they identified their legal, regulatory and contractual obligations. So as an auditor very early on in the audit this is a question I ask and I like to see has the organisation spot spotted that And if you're thinking about organizations that operate globally, then of course that might be even more complex. But what I want to find out is have they took these points into account. It wouldn't be a particularly useful ISMS if they've overlooked key legal obligations in the end. An organization needs to determine the scope of its ISMS, and the standard says the following: the organisation shall determine the boundaries and applicability of the ISMS to establish its scope. But as we can see, it's not just establishing any scope from anywhere. We should take into account A the internal and external issues we've just been talking about. The requirements referred to in 4. 2, that is to say the requirements of your interested parties, and this is an interesting one as well. Interfaces and dependencies between activities performed by the organisation. and those performed by other organizations. So let's take an example. Let's say we've got an organization, pretty much every organization I could give this for now, and it uses cloud services. So let's say you use a SaaS platform, software as a service platform provided by a cloud service provider. So I think we could all agree that a lot of the technical delivery of that service would be the responsibility of the cloud service provider. And the organization isn't necessarily going to put the cloud service provider and all its activity inside the scope of their ISMS But the management and oversight of that cloud service provider and the processes for that would be in scope. So we've got to look at what I I actually call it the reliance scope to some degree. degree. In other words, who or what are you reliant on? And if we drew dru do draw a boundary around that, how do you have some assurance and oversight? So this is an important point. And it says that the scope shall be available as documented information. So as I've said a little bit earlier on, as an auditor, I want to see the scope document and I really want to understand how the organisation arrived at the scope and And as I've said before, it's not about whether I agree or like the scope or don't like the scope, it's more does it make logical sense in terms of how they've got there. And 4. 4 is that the organization should establish and maintain and continually improve their ISMS. Well, in the end The fact of the matter is in an audit that's what we're trying to work out at the end of the audit, I want to really be able to say, is this clause fulfilled? Have I seen enough evidence of other stuff going on to say whether or not they have an effect? So let's move on to clause five then. Clause five is entitled Leadership and it has three controls, leadership and commitment, policy organization roles, responsibilities and accountabilities. So clause five, when we use the term leadership This is all about making sure that there is support and commitment from what ISO calls top management to run and operate an ISMS in the long term. So when we see this term top management This basically means that senior leadership within an organization should be overseeing and supporting the implementation of an ISMS. Now who top management are might vary depending on the type of organization we're talking about. So often when I ask this in a classroom, I'll say, well, what do you think top management is? A lot of people say things like directors, C level, you know, executives, etc. etc. And by and large that would be absolutely true. Now, obviously it's context driven to some degree. So I remember working with a uh a large global IT service provider helping them implement an ISMS But the ISMS scope was limited to some services specifically in the UK in this case. So I wouldn't expect the global chief executive necessary. necessarily to be involved in this case, but certainly the UK directors who were accountable for that business unit in that case were our top management. In a small business Very small business, it could even be the owner of the organization. So it will kind of vary uh vary depending on the organization. But what does the standard expect? Well, without going through each and every requirement A to H, because you're so you can read through those um in detail but I'll give you sort of a summary. What the standard is expecting is that those people in those leadership permissions support the ISMS in a number of ways. And some of them that are important are making sure the security objectives that we decide Define and the scope and so forth is aligned with the objectives of the organization, a bit like we were talking about earlier in clause four They should be ensuring that we have the necessary resources to run and operate that ISMS, not just to implement it. but to run it and operate it in the long term. Those resources might be financial, technological, it might be people. Now I'm not arguing here that management must have an open checkbook. and no budget, but what I'm saying is provide adequate justified resources to run the management system. Another key role that top management plays making sure that people in the organization are aware that this is actually a top management concern. So getting involved in communication, sharing. uh information with the wider organization. So people can see in reality that this isn't coming from an IT department or isn't a technical thing, but it's a concern of top management. And the more likely people see that, the more likely we're going to get back. in and also top management should be proactively reviewing the management system, ensuring that we are driving in continual improvement. This is why separately in clause 9. 3 we have this concept of management review. which we'll come to a little bit later. Now one way that top management can demonstrate their commitment is of course by establishing an information security policy So according to ISO, a policy is the formal intent and direction as expressed by an organization's top management. So, clause 5. 2 says we shall have an information security policy that does a number of things that's appropriate to the purpose of the organization. That includes the security objectives or if not includes them provides reference essentially. to those objectives. Includes a commitment to continual improvement and a commitment of satisfying applicable requirements. That could be legal, regulatory, contractual. requirements. Now usually what I would say here is an information security policy would be a fairly short document, maybe one or two pages that everybody in the organisation can see. It's setting the tone and direction. It's saying, okay, we top management take security seriously, therefore we're going to commit to the following things. For example, we're going to commit to implementing appropriate training. We're going to commit to ensuring risks are properly assessed and treated. We're going to ensure that we're going to monitor our ISMS, etc. There might be other policies produced later that are topic-specific, you know, topic tech technical topics like cryptography or network security or application security but we'll talk about them in annex A because there's a particular control in the there for that. For now, this is about top management showing that there is commitment and setting the tone and direction in policy. And of course we can't have an effective ISMS or argue that there's top management commitment unless people are appointed to actually run and operate the ISMS. And that's what clause 5. 3 is all about. establishing organizational roles, responsibilities and authorities. So who does what when it comes to running the ISMS? And who's authorized to do what? So, you know, who's doing the risk assessments? Who is it who's going to create policy? Who's responsible for handling incidents or conducting internal audits? We'd want to answer all of those questions And it clearly says in the standard, top management shall assign the responsibility in authority for ensuring the ISMS conforms to the requirements of this document. to the standard and reporting on performance to top management. So top management can't just allocate roles and then just forget about it. and there needs to be a link between whoever's performing those roles, for example an information security manager or CISO and top management. Note that the standard does not give us a list of job titles or qualifications or anything like that. Every organization will be different, but it should be very clear who is doing what. Those people should be aware of their roles and be formally authorised to do that. Based on the um authority of top management.