So next let's take a look at clause seven. So clause seven in the standard is entitled support and it covers five distinct areas from resources to documented information. So before we sort of look through these what I describe clause 7 as is the building blocks of the management system. In other words, these are all the things that would need to be in place in any organization for a management system to work effectively. So let's just take a run through and understand what the standard is requiring and some of the things we should be thinking about. So clause 7. 1 then says the following. It says that the organisation shall determine and provide the resources needed for the establishment, implementation, maintenance and continual improvement of the ISMS Now when we say the resources needed, these resources could be human resources, as in people, financial resources, so appropriate budgets. tools and technologies, you know, physical workspace if that's relevant. This is what we mean by resources. So what we're looking for is that the organization has Planned the resource requirements has a proper resource plan in place. They should be thinking longer term as well So one question I always like to ask is, you know, if you expand, for example, over the let's say coming 12 months, if that's in the organisation's plans, have they thought about how they'll ensure that there's adequate resource provision in this case? Particularly relevant with roles and responsibilities as well, do those resources have enough time? So there was a case with one organization where it was a relatively small business And the IT director was also named as the information security manager. And this person was perfectly able to do that job, except for the fact that they didn't really have time. Their IT director duties were so large if you like they didn't have the time to do that that would point to me as a resource problem. So have they properly planned that resource out over the long term Now if we focus specifically on human resources, not only do human resources the people need to have time, they also according to the standard in clause 7. 2 need to be what we call competent. And clause 7. 2 states that, without necessarily reading out every line, that the organisation shall determine the necessary competence of persons doing work under its control that affects security performance. That the organisation should ensure that those people are competent on the basis of what this is, education, training, or experience And where applicable, in other words, where there are situations where we need to improve competence, that those gaps are essentially plugged. And there should be evidence of that. So let's think about that practically speaking. So this means when an organization establishes roles and responsibilities for security, this should also establish the kind of skill sets that those people fulfilling those roles should meet. Now you won't find anything in the standard saying that somebody in a certain position needs to have X amount of experience or you need to hire somebody with this qualification. it's down to the organisation to determine that. A really good example of that I saw on a real world audit was a quite a large organization and they had a large cybersecurity function and they had what they called a competence matrix. So basically on on in this matrix they basically had one axis which was all the job roles in the cybersecurity function from SOC analyst to red team test right through to sort of uh your governance risk and compliance roles, so real variety And then across the top axis they had a bunch of skills described there from networking knowledge to application security to risk management. And each area on the map on the axis you could sort of plot it had a number assigned to it and that number was basically the required skill level for that role. from a level one, which they said was introductory or basic knowledge, through to level five, which was subject matter expert knowledge in this case And so the idea was you could look at any role and say what are the kind of skills and knowledge that the an individual within that role needs to have. And that organization used that to first of all develop its own internal employees so it could work with their staff to see where they might want to enhance their skills and provide them with training and support. They also used it as a career development mechanism. So if you were in one position and wanted to move or progress, you could see the kind of learning path you would need to take, the training path you'd need to take to get there And they also used that when they were onboarding new employees because they could actually then test somebody's competency through not just looking at their qualifications but maybe getting them to do some tests or competence-based activities in their interviews. So being clear about what the skill set requirements are is going to be important. Because you imagine running an ISMS and having individuals who might not have the required skills that could undermine things very easily. Let's take software development, for example. Let's say I have software developers who are not familiar with secure coding, for example, then you know that could potentially then lead to vulnerabilities which otherwise wouldn't have been present. So ensuring competence across the board is important. There's a lot we can say about that, but at this level, this is what clause 7. 2 is asking us to think about. Now that's slightly different to awareness, which is a much more broad thing. So when we look at clause 7. 3 it says The persons doing work under the organization's control, so that can be both employees, freelancers, contractors or even suppliers. shall be aware of the information security policy, their contribution to the effectiveness of the ISMS and the implications of not conforming to the requirements of the ISMS. Now many organisations tackle this by having quite a broad awareness program for both new employees joining the organization and for people there longer term. So you might think see things like e-learning activities, you know, awareness training sessions and so forth. But what we're looking for is what efforts are the organization making to really drive the right security behaviours in the organization Longer term that might be about building a strong security culture where people think about security almost as just being a normal part of their duties, not as a sort of a separate discipline. And again a bit later in the course we'll talk about as an auditor the kind of evidence you can seek out in this area. For example, looking at training records, I often as an auditor we'll choose a sample of employees and I'll interview those employees during the uh the audit. Not to catch them out or anything like that, but just to understand what are they aware of when it comes to security. Do they recall what training they had? Do they you know what do they think the most significant security issues are often just those kind of questions could soon tell you uh what levels of awareness are generally in place in the organization Now another thing that clause 7 focuses on is this topic of communication. So let's think about what we said in clause 4. We said in clause 4 that the organization should identify its interested parties, both internal and external. But it's not just a case of identifying them. Obviously to run an effective management system the organization and those running the management system would need to have regular communication with different interested parties. And there might be different reasons for that regular communication. It might be about giving interested parties an assurance when it comes to security. So for example customers, we might want to keep customers appraised of what we're doing to give them or instill and maintain confidence. It might be about support. We might be regularly communicating with our top management in order to get the ongoing buy-in and commitment that we need. Or we might be regularly talking to users in order to encourage the right behaviours. So for every interested party, there might be different reasons and purpose. for communicating. But what the standard says is we should essentially come up with a plan laying out on what we're going to communicate to who, so what kind of topics, how frequently we're going to do that and the methods we're going to use. Because every interested party, the way in which we communicate may need to vary depending on their level, their purpose, what they need to know. And so there should be a strong communication strategy and plan. And obviously from an audit point of view, I would want to see that plan, I'd want to see the examples of communication. And not only that What are the organisation then doing with that? In other words, is the communication effective? So, you know, it's great, for example, to send a let's say a report to top management every month on how we're performing from a security point of view But what impact is that having? In other words, is that leading to the desired effect of, in this case, let's say more buy-in? What sort of feedback are they the organization getting and are they adjusting it? But what we're looking for is on that ongoing communication. And one thing I should maybe just add to this is that the examples I've given there might seem a bit one way, like I'm talking about the organisation talking to its interested parties. Obviously communication comes back the other way as well and so how does the organisation manage that? So for example, let's say an employee in the organisation has a question about security and wants some help. Well, how can they go about seeking that? How responsive is the organization to that? Because if you could see gaps there, that could be a potential problem. You know, if people are coming for advice and not receiving it very quickly it might happen happen the next time round that they say well I won't bother I'll just skip that particular step. So we're looking for the overall communication plan and approach Now in any ISO standard, any management system standard, of course, there is always talk about documentation or documented information as ISO would put it. And I've heard sort of some myths if you like about ISO standards when it comes to things like this. I've heard people saying things like, well all ISO standards are documenting what you do or you need to create loads of documents in order to meet the requirements of an ISO standard. So two things to tell you there. It's not just about documenting what you do. Because ultimately you could be documenting things that you do that aren't particularly very good. So the point is it's about creating documentation that's needed to support the organization in doing tasks um well and doing tasks in a consistent manner. Also it's not true to say that you need to you need to create mountains of documents for the sake of it. So let's actually have a look at what's what the standard actually says and then we can work this out. So it says the following in clause 7. 51. The organization's information security management system shall include documented information required by this document. That's quite a mouthful isn't it? But basically documented information required by the standard So it is true that there are some minimum documents that need to be created when implementing ISO 2701, but there's not a huge amount of them. The main documents, I won't necessarily be able to recite every single one of them, but the main ones that spring to mind here are things like the scope. Of course, the scope needs to be documented the information security policy, the risk management process, the statement of applicability, the resource requirements. These kind of things you would expect to see, the internal audit process, you'd expect to see those documented. And how do you know if something is required? Well when you read the standard, if you see the words this shall be available as documented information, that's point A. But the myth bit about creating lots of documents is the bit in B, point B, 751B, which says documented information determined by the organization as being necessary, key word, for the effectiveness of the ISMS. So what you've sometimes see and I've certainly witnessed in real life and I shouldn't criticize consultants because I am one myself but I sometimes see consultants who are going to an organization They'll look up clauses 4 to 10, all 93 security controls and write a document for each one. Well there you are, here's a huge bunch of documents for you and guess what happens? Those documents don't get read. You might end up calling them shelfware. You might have heard of that term before, just documentation that isn't looked at. So that's not what the target is here. We've got to determine what documentation we need. So if we're in a complex environment with a complex task, let's say a system administration task that we need the system administrators to do consistently in detail, then of course something like that you'd expect to see a detailed document with step-by-step instructions. Maybe for simpler tasks, lower risk tasks, where we have a highly competent workforce, the level of documentation won't be quite the same. An example from an audit I actually give when I teach this course is the following one. I did an audit of an IT company that had 15, that's 1-5, employees. Uh and in this audit I um spoke to the uh the basic the owner of the company and we were talking about HR security and I asked him about the leavers process. So I said, can you take me through what happens when somebody leaves And how do you ensure that you remove all system access when they've gone? And he said, well, being honest with you, in the last five years I've only had two people leave the organisation, but here's what we do, and he talked me through it And I checked the uh all the uh the various systems, the Active Directory, a few other applications. I could see that those accounts had been removed. I'd seen an email to the administrator confirming this. So I was happy that the two individuals we're speaking about had had their access remote So I asked him, I said, if you're not here, given that you know the process, well what would happen then? And he explained how his colleague also would cover this and I interviewed that colleague separately. So long story short, by the time I'd done those interviews and looked at that evidence, I was satisfied that they had managed those levers effectively. But I asked the classic question, which is, you've verbally explained this procedure to me and I've seen evidence that it's happening. But have you documented it? And the answer that came back was no we haven't. We haven't written a document. And then I have a decision to make as an auditor. Well the standard doesn't actually say, believe it or not, that there shall be a document So in that organisation I took the view that what I've seen is effective. I did raise an opportunity for improvement and I said to them, if you grow and there's more people involved then this is more complex. You probably ought to document this, but certainly it's not a mandatory requirement. Now had I have been told that story in a company with a a thousand or two thousand employees, I would have taken a very different view because the lack of documentation could mean that the process would be ineffective. So this is the point about point B. Every organization is different and especially as an auditor you just need to think about the proportionality. Documentation should always add value, not just be there for the sake of ticking boxes. Now one thing that is important for the documentation that is created, whether that's created in Word documents, on wiki pages, in products like Confluence or wherever it might be is that the organisation has what we call a document life cycle. There should be some rules that specify how documents are created and who can create them. So maybe some levels of authorisation There should be some information about how the organisation will identify those documents. Is it a policy, is it a procedure, including the classification and security level. So in other words, is this a document that is limited to internal use only, limited to a certain audience? Does it have a certain level of sensitivity? If the answer to those are yes, obviously I would expect to see security handling rules in an audit, we'd be testing that as well to see if those security rules have been followed. What are the rules about modifying documents? So do we have access restrictions to stop people simply making changes to documented information unless they're authorized? And I'd want to understand the approval process. Now approval processes may differ. A corporate policy may need a different approval channel to a let's say a local procedure in a given department. But how does that work? I'd also want to understand how documents are actually distributed. It's one thing to have good quality documents, but how do the people who are meant to use them know that they're there? So how do we share them with people And of course we can test that in real life during an audit by looking at the documentation people are using, asking them questions about it So recent audit I did, for example, the organization had launched a new AI policy just a few weeks before the audit. So when I did my awareness interviews, I asked a number of people, I just said, have you seen the AI policy? Where would you find it? And I wasn't grilling them on their knowledge, it was more about could they find it, did they know it existed, you know, could they consult it if they needed it. How does the organisation check whether the documents are being used adequately or not? Again, in other words, are people actually referring to them? Are they actually following what's stated in these documents? That can be discovered through things like monitoring and metrics, through the internal audit process perhaps. These are all relevant points. And then the last two bits, archiving and disposal. Depending on the information or data retention policies of the organisation, there might be a point in time when organisations archive documents, that is to say keep them, but just store them for the longer term. And there may be a point when they actually decide to destroy or dispose of those documents. Again, I'd want to understand what the rules are about that From an archiving point of view, are there any security rules? How are those archives protected? Now thankfully the vast majority of documentation today is electronic and there are electronic archiving solutions Back when we had a lot of paper documents, I'd have to concern myself with physical archive storage, for example, and how secure or well protected that might be. And then disposal, the way in which data is destroyed, might vary depending on sensitivity. So there's no right or wrongs for all of these, but there is an expectation that all of these points can be answered. Now typically that would be answered in a document management policy. So an organization really ought to have a document management policy that answers all of these. The last point I want to make on this is if an organization who is implementing ISO 27001 has another management system in place, let's say 9001 for quality it might be that they already have these processes in place and could essentially reuse them because all ISO management systems have the same demands so that's always something to explore as well.