S3E04. ISO Series - So you're ready for an ISO Audit (or are you) ?

Hey Doc, so after listening to you the last three episodes, I think I'm convinced and I'm ready to try to take the certification. So how do I know whether I'm ready for it or not? So congratulations, I'm happy you've taken the step towards going to certification. So your question is how do I know my organization is ready for certification? Welcome, you are listening to Securitilla podcast, season three. I'm sure you have read through the ISO standards. We've gone through it in the last episode. So through chapter one to chapter 10, you would see that you have a number of things that you need to get done, right? So you identify the scope of your organization. You need to make sure that your senior management is involved in the process. What kind of support that you need from the organization, resources, people, awareness, communication, and key thing in ISO is documentation. So you need to make sure that every single process has some, I would call it as a document residue, meaning that if a process is completed, there's enough documentation or trails or system that keeps track of things that are going on. It can even be as simple as a ticketing system, which has all the details that you need in order for you to track something. You also look at monitoring performance, how well is your organization doing and what are the steps that you've taken to do improvement? Now you need to complete one cycle of the Deming model. So the Deming model is PDCA, which is plan, do, check, and act. So what does it mean? So in the plan stage, you're looking at planning to implement your organization, ISMS in your organization. So you should have done that, right? Next one is do. In the do stage, you are actually putting in all the controls, you're testing the controls, you're making sure everything is fine. When someone leaves the organization, you check to make sure they hand back their badges, their laptops, and if their laptop has no further significance, you clean wipe it and you redeploy it. So you have all the necessary processes in place and it's working like clockwork. So you don't have to worry about whether it's running or not. Then the next stage, which is check. In check, you look at your internal auditors or you identify auditors who will act as internal auditors who should be, in my opinion, have gone through the ISO 27001 lead auditor certification training. They must have finished that certification training so that they would know how to audit ISMS. They should now come in, look at the whole organization processes that's covered under ISMS, audit all these processes. Maybe they may not look at the whole entire organization. They might look at say 70 to 90% of all the processes that they find, okay, these are the critical processes. I want to make sure they're audited. You take samples, you check the samples. Let me give you an example. Physical security. I like physical security. So you want to make sure that physical security systems are updated with the latest information. So if when you're looking at the door access, you ask for the latest list of users who have access to the door or who owns an access card, right? And then you ask HR, hey, HR person, can I get the list of people who have resigned in the last three months? So that list is probably not that much. You can use that list and you can compare the list. So if the person who has resigned from the organization still exists in the physical security system, you have a problem. That's immediately a finding and that will help you identify that there are shortfalls in the processes. So I'm just giving an example of how the audit process looks like, right? And once you've identified all these things, now based on the methodology that is prescribed in ISO 19011, that's the standard that the auditors will use to audit the management system. Then you bucket your findings into just say these are findings, which means you have to fix it. It is a problem. Then you may have recommendations or need for improvements where they recommend certain controls should be tightened or should be reviewed more frequently due to the importance of the priority of that particular system. So once you've done the check, now you have to act based on the recommendations that's given to you by the auditors to say that these are the findings, we have done this and we have closed this issue. So you finish one whole cycle of the PDCA, once you've done that, then you are ready for your certification. During your certification audit, the first thing you do is identify who do you want to be your auditor. So if you're comfortable with your local standards body, so for example, in Malaysia we have SIRIM, then you can employ SIRIM to become your auditors. If you're a multinational organization that is based on US, then you might call PECB or NIST to come in and do the audit for your organization. If you're on the UK and the Europe side of things, then it would most likely be bodies like BSI or an IRCA based audit organization. So depending on which part of the world you are, then you can select even the big fours, the audit firms will have people who are certified ISO auditors who can also assist you in doing this audit. So at that point is when you know that, okay, I am ready to be audited. It seems to me there are two components to it. First is the internal team where you talk about the plan, do, stuff like that. And that's where you make sure that you have the necessary mechanism in place to ensure that there is a continuity in terms of monitoring and also improvement. And the other component would be more on external in which it would involve a team of auditors who will come in with your duty check part. And then with the outcome of the checks, whatever mistakes or errors that is identified and then you rectify it and that's the act part in it. That's correct. So the first thing to do is internally you need two teams. You have one team or one person, or depending on how big your implementation is, you need to have people assigned to do the implementation and the operation of the ISMS. So you need someone to run the management system on a day to day basis. And then you have internal people who are trained as ISO auditors to then do an internal audit of this system that you have implemented. That's the internal side of things. For the external side of things, this is the organization that you want them to give you a certificate. So for example, if I want a well reputable organization, then I may say, okay, let me go with either BSI or SGS or whomever that you have presence in your country that does ISO stuff. So they can actually come in because they would have certified auditors. These auditors can now come in and help you do the audit. But I think it's not always obvious that there is this PDCA in place. Is there anywhere in the security documents that we are able to identify that such a mechanism is in fact running and implemented in the organization? Okay. So as far as PDCA is concerned, you will learn about PDCA when you go for the lead implementer course. So ideally in organizations that wants to do ISO 27001, there are two trainings that you'll have different set of people attending. The first one would be the lead implementer training that talks about how to implement ISO 27001 in your organization. The second training is the lead auditor training, which talks about how do you audit management system in an organization. So in this case, you look at auditing specifically based on ISO 27001. So these are the two skillsets that you will need to have people to know. And in getting these skillset is where you have the knowledge or the exposure about PDCA. So PDCA is just a model that tells you this is how you implement ISMS in your organization. So you can say that the PDCA is just a model that you have taken. You may decide to use other models, but then you must be able to show that you have run through each phase of the model. That's where the documentation bit comes in. Okay. What are the alternatives to PDCA? Unfortunately, I don't have it on top of my head. I know I have a few models, but I can't recall at this point in time. When I do, I think what I will do is I will get our social media admin to put it up in our LinkedIn site as a reference so that those who are interested check out our LinkedIn site and we'll probably put some details about what are the other alternatives that we have besides PDCA. So I would assume that even if there are alternatives to PDCA, then they will also have to go through the audit process. Yes, of course. The whole idea of ISO is you have to go through PDCA. You have to go through a certain model for you to say that you've done one cycle. To say that you've done one round of implementation right up to the end, we are saying that we've done this and we are actually ready in the event that anyone wants to see whether we've done everything that we need to do. And just now you also mentioned multiple audit parties. How do we know which one to go to? Is it it depends on where you are based or is there any other criteria? Okay, so earlier I mentioned about the internal audit team versus the external audit team. For you to implement ISO 27000 series or any ISO requirements, as long as you complete PDCA, in fact, if you notice to complete PDCA cycle, internal auditors are sufficient. Where the external auditor comes in is when you want a cert from a third party to independently say that I meet all these requirements and I have been audited independently to show that I've met all the requirements. So they will sign the cert and tell you. Say for example, Prof, you're an expert in multiple domains. But you can't just go out and say, hey, I'm an expert in all these domains. You'll have to get a PhD in a university or sit for a certification exam. So you've got to do a number of things, right, Prof, for you to show people. You can of course say, yeah, you know what, I'll just write a few papers and I'll publish it. Well, you could do that. Nothing's stopping you. But yet, you know, you've gone for university, you've completed your doctorate, you've done all that you need to do. Now the role of that university giving you that doctorate is that external auditor. They have audited your knowledge and they've identified that you are now sufficient to hold the title doctorate in order for you to go out and say that, hi, I am an expert in this particular field. So that's how I draw parallels into the internal team versus the external team. I think it's to a certain extent, yes, because there are basically many ways for us to decide and ascertain whether a person is an expert or not. Not only by going through formal education and so forth. So if I look at this one back into the context of a discussion, does that mean that having an internal audit alone and if you have passed through the audit properly, that is enough to say that you are certified in that sense, in a certain sense, and that you are well equipped to protect the organisation from threats. And what would be the value of having an external certification? There's two parts here. The first part you said sufficient to manage threats and the second part you said certified. You can only get certified through a third party. Self attestation is not certification. Okay, fair enough. You can always say I'm secure, I'm secure, but you know, unless if you have someone auditing you only then you know whether you're secure, right? So in that instance, the value of the certification may be because it will enhance your business image or maybe it's a requirement for you to bid for a certain tender. They may say that, okay, we will only accept bids from organisations that are ISO 27001 certified for this particular area. Is there an in between, like you don't go for an actual certification by a certification body, but you hired some external second party audits? You could do that as part of your internal auditor. So for example, in the checked part, you can either use your internal auditors or you can even hire external auditors to play the role of that internal audit. You can do that. And you can then say that to have complete transparency of the whole process, the report is then floated up to the management committee that you have, your ISMS committee, and it's also floated up to your board of directors. You could do that because end of the day, if your focus is I want to adopt the standard, but I want it to be internal rather than something that I shout out, that's entirely up to you. So ultimately the difference is that you have proven in terms of operations that you are well secured. And you have proper mechanism in place. I have to correct you that. I can't use the word well secured. I would rather use the word that you have the processes in place to handle cybersecurity because the problem when we say you're well secured, it gives the impression that hackers can't get through. On the other hand, we have done everything that we can, but still we do not know whether we are really good enough or not. So that's why I say I go back to that Pareto model where I say that you've done 80% of the things that organizations should by default do to take care of their cybersecurity. Now there's always the 20% of the part where it's either your blind luck or you're a target or whatever in that instance where you may still get hacked. For example, we spoke about SolarWinds attack, which was a supply chain issue, which affected large organizations, which even affected security organizations like Mandiant. When you have that kind of attacks in place, it's only as best as how well you manage the situation. So the reason why Mandiant was able to detect that attack was that they had processes that look through their internal organization and they found something was wrong and they reached out to Microsoft, they reached out to SolarWinds, they reached out to a number of organizations and they found out that yes, something was fishy, something was wrong and they were able to get to the root of the issue. Now that bit of the methodology, that incident response, incident management is there as part of ISO 27001. So if you have implemented all the processes, rest assured you have the process in place that you can rely on in the event something breaks, which means that you're not running like a headless chicken figuring out that the sky is going to fall on your head, but instead you are calm, composed and you just go back to your processes and you say, okay, these are the things I need to do, right? Stem the bleed, look at the severity, identify whom needs to know this. I don't bury it under the carpet and hope nobody knows about it and suddenly it blows in your face. You don't do those kinds of things. If necessary, you create a war room or you invoke the crisis management team. You make sure that you have corporate comms beside you so that you can craft a message in the event if it affects multiple customers and all that. I think we covered this a little bit in one of the episodes where a local payment gateway was affected. IPAY 88, right. So we spoke about incident management and response and we covered in detail as to what are the areas that they did well and what are the areas that they didn't do so well. So when you have ISO 27001 in place, you would have drafted all these policies, you would have put all of them in place. So at the point where you need them, they are there for you to invoke. They give you a guide as what to do because in crisis situations, truth be told, a lot of organizations really lose touch of what they need to do because they panic. They don't know what they need to do. So that is why in a lot of times when organizations hit crisis, they often get an external party to be their anchor, so to say, to manage the whole crisis situation, understand the communications between different parties, make sure the updates are going in on a regular basis, manage the whole situation effectively. With ISO, you would have these processes, you would be better off than an organization that doesn't have any of these processes, doesn't know what to do and probably may end up doing things that cause more damage instead of doing the things that they should be doing. Or probably a case of having just bare enough as opposed to having more. Yeah, sure. So in some instances, some organizations may say, I may not want to do all the security processes because I will need headcounts and all that. I will just conveniently outsource it. So when the time comes and I have say an incident, then I will invoke my contract with the incident managers. They will come in and manage the incident for me, which is perfectly fine. ISO does not tell you that you have to do it yourself. You can outsource the process and as part of your audit process, your auditors will now check with all these vendors on their process to make sure that they have sufficient processes in place that meets ISO 27001 requirements. But I think in any case, any organization would do well with an internal team that could also check the work that's being done to ensure that at least some form of adherence to standards are maintained prior to going forward with recertification. Yes, you're absolutely right. So the ISO certification, the external certification process works this way. The first time when you do an external certification, it's a thorough process. They will look through everything and they would also look at how thorough your internal audit is. So if your internal audit is really thorough, it will be a breeze on your external audit. If your internal audit is very simple, then your external audit will be quite thorough. They would want samples, they would want data, they want to check a number of things. So you have to have a balance between how well the internal audit for your ISMS is performing that would determine how your external audit comes. So when you have... Can you elaborate? Sorry, please continue. So let me explain, if your internal audit does a really good job checking 95% of the processes, now it is redundant for the external auditors to check the same process because what they would do is they would also read through the audit report. As an external auditor, I read through the audit report to see how comprehensive the audit is done. So for example, back to the example I gave earlier about physical security door access. If I see that, yes, there's an audit being done for door access, but they only looked at the last one week, I might say, "Well, that's not sufficient. I want them to give me three months of data." So then as an external auditor, I can come in and say, "Can you give me three months of data?" Even despite what the internal auditors have done. Because then end of the day, if you're not gone back long enough, how would you know that all the necessary controls are in place? You can even go back as far as one year because end of the day, your PDCA cycle takes about one year. So you can just say, "Okay, as an external auditor, I want one year of data. Let me have a look at it. I will just quickly compare. I just do a Delta, then I'll know whether the data matches or not." These are things that you don't have to wait for the auditors for you to do. You can even check as people in operations, you can check. Say, "Okay, guys, I want to check the physical security access. Can you give me the system listing?" Because end of the day systems are usually managed by information security or a team that's handled ID provisioning. So in organizations that have that kind of setup, then it's very easy for you to even check yourself rather than waiting for the internal auditors. And you can even file in to say that, "Yeah, we've been doing this check on a monthly basis. This is the check result out of last nine months." And that can also serve as evidence for external auditors. So if I'm seeing that, "Hey, okay, these guys have been doing their job thoroughly. Okay, very good. I don't have to check this section. Let me look at a different section." So that's what I meant by the thoroughness of how the process is implemented. And that would also mean how an organization balance between internal audit and external audit. Yes. What about documentation? Is there any general guidelines for good practices? Let's say if you were to set up a team, like what you just said, to audit one another internally. And what are some of the good practices to documenting these things? The first thing is sufficiency. Does the document show sufficient information? Now I'm using the term document loosely because not everything needs to be in a Word document. I mentioned earlier, information can reside in systems. So as long as you have access for you to pull information from those systems and the systems actually store this information as to whether a process is done, that's good enough. I'll give you an example. You have IT help desk in almost all organizations. So when a case is locked to say, "Hey, my keyboard is not working." That should make keyboard is okay. Anyway, for an example, my keyboard touch is not working. So then a case is logged in the ticketing system, the service management system. Now you have all the trails to show that the engineer actually visit the user, check the keyboard, confirms whether the keyboard is actually working or not. Maybe just a loose connector, gets all this tested, gives the recommendation and then says, "Keyboard memang koyak" or "Keyboard is not working. We need to change the keyboard." And then you order the parts. When the parts come in, you go back to the user, you replace the keyboard and the user is happy. You close the case. Now in this instance, the ticketing system will have the flow and whatever that happened for that particular service request. So in that way, you can check from the system itself. I'll give you another example. You have policy documents. Now policy documents usually come in the form of PDF or a Word document. Primarily Word document because you want to modify it and it's crystallized into a PDF document so that you don't change it. It's final. Right? Now in this instance, what's important is number one, document versioning, which is what version is the document running. Secondly is the changes that's been made to the document, which is version control. So version 1.0 was the first official draft. 1.1 approved by board, published for everyone. 1.02, we are doing some minor review for the new year. 1.2 signed off and approved by board based on the changes that's given. So you have a log that shows that the document is reviewed and is changed. The reason why you need this is because in some of the controls, they want to make sure that you review this processes or this SOP or guideline or document on a periodic basis. So if you've not done that review, that means you've not met the requirements, which means that you failed the control. So having this version information and the change control would help to justify that the process of reviewing the document is in place. What's the usual timeline for a review? For example, for policy documents, it is recommended one year. So it's one cycle of your PDCA. And then by the time you do your next cycle, you've requested for a set of changes because what happens is sometimes in the check phase, there may be recommendations to change your policy. For example, your policy might say that, "Oh, we recommend a minimum of five character passwords." Now we all know in today's world, five characters is not good enough. You may have an audit finding that says, "Industry standards dictate that five characters is no longer good. We recommend a minimum of 10 and above supplemented together with two factor authentication," for example. Then that's a finding. So what you can say that, "Okay, these are all the findings. We have the next policy review coming up in say six months time. We recommend to put this into the next review." And you may say that, "Okay, audit findings." You say, "Okay, fine. It should be published in the next review." We close it. It's been agreed and it's been tabled in the management forum. Management forum agrees. Yeah, it should go into the next review. So in the meantime, we will implement the process. So one of the interesting things I have discussion about processes, and maybe I could pick on your brains a little bit prof on this. Which one comes first? The process document comes first or the actual implementation of the process comes first? Enjoying the show so far? Subscribe now so that you don't miss out on the latest episode. We are available on Spotify, Apple Podcasts, Google Podcasts, and many other platforms. Visit podcast.securitylah.asia to get the links to subscribe. I would think the documentation should come first because there must be some form of guideline that goes in it. Once you implemented the process, the outcome of the process, depending on the requirement, then it will add on to the documentation. Good point. Here's the problem. Your policy is now approved. You need to implement two-factor organization as part of your policy. Three months down the road, internal audit comes and does their annual audit. Looks at the latest policy document and sees how shall implement two-factor. Goes and audits five critical systems, realizes you don't have two-factor implemented. Now, based on what you just said, you get the policy document approved first and then implemented. You see where the problem happens? You now have a finding that says your policy says you must have two-factor, but your actual implementation isn't there. If you have a policy that is approved, then it should be implemented. How could you go for an audit when there is a difference between what's written and what is in practice? Because what happened is what is written is based on what is approved. The company should mirror what is approved. True, but that's the problem. Then reflected in the written documentation. That's what my question is. Which one comes first, policy document comes first or implementation comes first? Your answer was... When you implement first, then only you design and document them. Why not? Because when you do that, what happens is the control is in place. Your policy merely states what's in the operations, right? Like what you said earlier. Shouldn't the draft, the policy should come up first and then based on the policy, you design the procedures and then you implement the procedures. Well, that's an interesting point of debate, right? But you see, that's the problem you will get into an organization. Your policy is approved, audit comes and checks and says you have not implementation. So just a quick answer to that. One way is to say that for each policy statement that is recently approved, it should be backed by an implementation timeline. Yeah, of course. But in reality, if you look at it, the policy gets approved without an implementation plan. I've been to multiple board of director meetings. I've seen a lot of time policy approvals, policy proposals without an implementation timeline. So what happens is policy is approved. It is assumed that you have the budget. It is assumed that you have the resources. It is assumed that it is in place and it's running. How can an organization approve based on assumptions? Because they approve based on documentation, not based on implementation. Then the documentations are not up to mark. Policy document doesn't talk about implementation. Yeah, but if you want to implement a policy, isn't it right that we also consider how realistic and practical the policies are? Give you an example. Just say you're moving from five character password to 10 character password. Just that one example, right? Now, if you were to sit down and do a full TARA study, it may take you two to three years before you can identify which system can be upgraded to 10 character passwords, which system can only go up to eight, which system cannot meet the complexity rule, blah, blah, blah, blah, blah, and all that. At the board level, that's too late. Well, pardon me, but if that is the case, then I'll say the whatever decisions have been made, they were made without thoroughly understanding the problem, what it is, and whether it is a feasible solution, which is practical enough to be implemented. Welcome to the corporate world. You can always aim for the sky and the moon, but at the same time, can you get there? You'll be surprised. That's actually what's happening. This is what's happening. This is actually part of my own battle with the boardroom, because with the boardroom and specifically with the audit team, because when I deal with audit teams, both internal and external, the only thing they say, hey, your policy says this. How come you never do? That's all. That should never have happened, and which is precisely why I question if something that is very prescriptive, I've used this word a number of times, and how implementable is it? How realistic are those things? Number one, it doesn't cater for any organizations to adapt, to be agile and adapt to changes and stuff like that. Do they provide all these things? Otherwise, policies will always remain with policy, and without proper planning, then nothing gets done. See, prescriptive is subjective, because for example, when you look at the ISO document controls, for example, one control is your policy document must be reviewed periodically. Now, to some people, they say, hey, that's very prescriptive, but to me, I still see some leeways, because it says periodically. First thing you have to define which falls under the category of your policy documents, right? Now, that's up to the organization to define. The next one is periodically. Organizations need to then document to say, we will review our documents annually, say, in the first half of the year, example, right? Then all your documents get queued up to be approved by the board on first half, right? So that's from a process perspective. So you see, to me, I think that is the same argument. Number one, there is nothing wrong with giving a guideline to say that something needs to be reviewed periodically. Secondly, the question is, how do you define periodically, which is exactly the timeline that is missing in your process and implementation documentation? Yeah, so that's where you have to put in. You see, in that instance, the ISO document is not prescriptive. It is up to the organization to decide how they want to meet the requirements. The requirements are there. The same thing as the example I gave earlier about firewalls and router access lists, right? There's nothing in the ISO document that says that you must use a firewall of this brand X or brand chicken or brand duck. Nothing of that sort. You can pick whatever brand you want from whichever country you want. Nobody's going to say anything about it. As far as the auditor is concerned, oh, you got packet filtering. Very good. Do you have logging enabled? Good. Is your user listing, you're not using default admins and all that? Very good. So if you look at it, the audit process looks at the controls in a holistic view. You don't just look at one thing and then you pick and say that it doesn't work that way. You have to look at the system holistically and understand it from the context of the organization and the business. So that gives a room for organizations to determine how they want to do it. Of course, there are industry best practices. For example, document review should be once a year. Right? That's an industry practice. So most industries, they will publish their benchmarks to say we've done it on an annual basis or in some organizations where they find that the situation changes so rapidly, you can't have an outdated policy document, then they might reduce it, say, to six months or eight months or even 10 months, depending on what the organization feels comfortable about. Again, it goes back to the organization. ISO doesn't make all the decisions for them. ISO just tells you these are the controls. You decide how you want to do it. If you think this is good enough, fine. But if it doesn't meet the industry benchmark, the auditors can still recommend and say this is what it is. Now, in some event, you may then tell the auditor, say, for our industry, we find this is sufficient. These are the supporting documents. And we feel this is good enough for organizations. The management support this and fine. Finding gets clear because then it will be under one of those categories called risk acceptance. So I'm not going to change my policy once a year. I'm going to change my policies five years once and my management has accepted the risk. When we say we don't see any critical risk, this is fine. We can make do with whatever policies we have for the next five years. Example. So that means we can say the ISO 27001 is a framework that tells you what you need to have, but not how you should do it. Yes, exactly. So it gives you a set of controls that you can start looking at to say, OK, these are all the controls I need to do. Like what I said earlier, you're going to an organization. Where do you start? What controls do you need to do? How do you have a checklist going in? Say, for example, in a greenfield, it's kind of straightforward. Greenfield means a brand new organization that has nothing set up. You take this as a checklist and you start implementing one by one. You pretty much have everything up and running. What about a brownfield? A brownfield is when an organization that has established itself over time, probably have people doing cybersecurity work. And you've now been appointed as a CISO to go into this organization. Where do you start? What do you do? How do you approach things? You can use the same Deming models for you to say that, OK, let me look at this whole organization. What are the things that are there? What are the things that are not there? I can start off with a gap analysis. Identify what are the gaps. I use ISO 27001 as my reference. I identify the gaps. I go back to the bot after two weeks being in an organization. I say, I've done a quick gap analysis. This is what I see. It's in place. These are the things that are working very well. These are the things that are not there. The methodology I use is ISO 27001. And this is the framework that I would like to recommend for the bot to adopt and adapt. And we want to use this as a framework for us to implement and ensure that cybersecurity is implemented as per international standards. The way I see it, the standard tells you what is required, but it doesn't tell you how to do it. It gives you that kind of flexibility. And yet it came up with another standard that tells you, another group of people, how to audit. Or is it still what do you look for when you're auditing this standard? See, what you're looking for, for example, I go back to that first control. Your policy documents shall be reviewed periodically. So the first question is, what are your policy documents? That's the first thing the auditor will ask you. Can you give me all your policy documents? So you gave five to 10 documents that talks about cybersecurity. Okay, good. You have documents. Now, is it reviewed periodically? The first thing I do is I flip to the second page where you have version control. So based on the version controls, I see, oh, this version has been this version. It was approved by this. These are the changes made. And you have some description about why the changes were made and all that kind of stuff. So based on that version control gives me enough information to say, you have approved this document in whichever minutes of the meeting. If I want to become a little bit more pedantic, then I would say, okay, so this was supposedly approved in this board. Can I get a copy of the minutes of the board meeting, confirming that this document actually went and got approved? So I go to the company secretary and I ask them, okay, can I get this minutes of this meeting, this meeting, this meeting? Obviously the company secretary is going to ask, why are you asking me this? Or we need this as part of the ISO 21001 audit. You get a copy of the minute. Or sometimes they may say, we don't want to give you the whole minutes. Tell me which section you want. We will extract it and we will certify the extract. So say, okay, I want to know if there's any policy that was approved during this board meeting and give us a list of the documents that were approved. So then the extract will contain, okay, so the committee discussed these documents. These documents were approved. These documents were sent back for review. So based on that, it confirms that the annual review or the review has been done for that particular document. So you see how the methodology works, just one control, but you see how many things you can spin off to. Yeah, that's quite complicated. But you know what, Doc? I find it hard to come to terms with the fact that policies are, in practice, policies are approved without specifying a period, a transition period or something like that. And as a result, that creates that kind of inconsistency that you brought up between policies and documentation. This is a reality in today's corporate world. I'm like, how? And why? Because what happens is the policies looked at a document from a governance perspective. A policy document is a document that says how the organization is supposed to be governed. Policy documents most often, depends on how organizations write policy documents. For me, policy documents contain motherhood statements. Motherhood statements are like, for example, like what the ISO said. Policy documents shall be reviewed on a periodic basis. Then you probably have another document standard that says, all board policy documents shall be reviewed on an annual basis. All management policy documents shall be reviewed together with the CEO on a biannual basis. SOPs or guidelines shall be approved and reviewed on a need-by basis. But there's somewhere that you need to define this. Do you know that there are organizations that have policy documents who don't define documentational standards? Because when you ask them, how often do you review your documents? Oh, we review them manually. Okay, very good. Where have you specified that you review them manually? No, we just know we do it manually. Yeah, but where do you specify it? How do you know which document should be reviewed annually? What documents should not be reviewed annually? Do you have a documentation standard? A standard that governs how documentation works in your organization? Do we need one? That's the kind of discussion that goes on. Even at a very basic level of documentation and policies and guidelines. So it's actually a thorough process. That's why organizations like financial organizations or even telecommunication organizations sometimes have dedicated departments that purely handles documentation. Making sure that all the documentation meets the standards, goes through the right process, they are reviewed based on their terms. And any new document is put onto a document register and is managed according to the process. I can only say govern is a verb. Yes, it is. I don't deny that. There must be some form of action. You just define something. They cannot be separated. They cannot be separated so that governance is to act in the interest of the organization. I'm surprised when you go into even some large organizations, when you ask very fundamental questions, the first reaction is you should know this. Okay, good. I should know this. If I'm a new staff and I'm just coming to the organization, where do I find information about this? You learn about it. You know, when you are thirsty, you drink. And only that will quench the thirst. You don't draw a cup of water. You see, whereas this is where governance differs. Governance even tells you that make sure the cup is there so that when someone is thirsty, and make sure you tell people where to find that cup. Right. Now I know. Looking at the well and then quenching my thirst. This is mind-boggling. Yes, so this is a huge rabbit hole that we can get into and I don't think we will finish discussing about just this topic. Because as you can see, how such a simple thing can have a profound difference in an organization. Yeah. Because you should discuss these things. And that is precisely why we need standards, right? To guide and tell us what we should do and how to do it. And you should even have a standard to define how standards are. Oh, yeah. It's a meta-standard, you see. Yeah. And then just make sure we don't end up with a lot of standards and then no action. See, that's why I raised that issue. Because I was in an organization where we were asked to put the policy first. So like what you said, it makes sense, policy first. But then what happens is we kept getting caught on audit. Because audit says, look, your policy says this, you're not doing this. And there became a finding. Yes, it's true. And it's non-compliance. Yeah, so after a few rounds, we realized that this is not going to work. So we said, we're not going to do this practice. If a policy statement is going to go up, it's going to go together with a separate table that's going to give implementation timeline and the budget approved. What we need for us to meet this compliance. Essentially, when they make the decision, they're not just making a decision on a policy statement. They're making a decision with the impact to business. So if that's the case, then you would have implemented the change first and then update the policy? You could do that as well. Nothing's stopping you from saying that, okay, let me implement two-factor for all my VPN servers because of MCO. And then I say, we will update the policy to say that since we already have it in place, it's running, it's auditable, someone can validate it, the governance processes are there. I can then go and update my policy to say we have updated all VPN systems. So from today onwards, please make sure that all VPN accesses are granted with a two-factor token or a two-factor QR code. So the implementation is from today, the compliance is from today. But what about the policy? Is there a timeframe as well to update? The policy comes in at the point where it gets approved. So if the policy gets approved two months after implementation, well and good, by then, you've already gotten your masses into, say, your two-factor token, everybody's deployed. And when the policy comes in, the audit team comes to check if there's any accounts in the VPN server that only uses password and not two-factor. Now that becomes a breach. Okay. Right? Does that make sense to you? Yeah, so I guess I'm a little on the flip side of things now. That's how I feel. So you actually implement it and then get the documentations in order. Yes, because to me, that works. Or if not, because the other challenge is this, here's another conundrum. I know we're stretching the episode a bit because we're in a very hot discussion. Now here's the thing. You go in, same example, VPN, you want to implement two-factor, you get the policy approved, your annual budget comes in, your budget doesn't get approved. What happens to audit? But you have implemented it and then your budget don't get approved. No, no, no. No, no, what I'm saying is I'll repeat the scenario. VPN and two-factor, you've not implemented two-factor yet. You've written the policy, you have sent the policy up to the board, board says this is good practice, we should have two-factor, very good. Okay? Now year end comes, your policy is approved, you write an approval, you write a request to get budget for you to implement two-factor tokens. Business didn't do so well because of MCO, they said, no budget for two-factor. Guess who comes in next, audit. Guess what's going to happen. So that means when they present the policy for approval, nobody ever asked about how much it will cost for us to get this done. Because the policy discussion is purely a philosophical discussion about what should be in, not how it should be in. That's interesting. See, the thing is this. That means you approve something without considering whether it's viable, whether it's feasible, and whether it is practical for the longevity and sustainability of the very entity that's going to implement it. So here's the thing. Let me look at FSI for example. Before risk management and IT in Malaysia was approved, there was no requirement to have IT-savvy board members part of board. If you go to a lot of boardrooms in a lot of organizations, you barely find people with IT experience in the boardroom. Chances are 99, if not 100% of the people sitting in board are all finance people, number crunchers. So when you come up with these kind of policies, it's usually just brushed through."Ah, this ah, okay, okay, IT ah, oh, you're doing two-factor, okay, very good, very good, ah, sign, go, finish." All right? First thing they ask, "What's the change?""Oh, we're going to implement two-factor, boss.""Ah, okay, okay, very good, very good. I heard two-factor, very secure, very safe, very good. Sign off, ah, okay, go, thank you, finish." Less than five minutes or ten minutes is discussion on IT, technology, cyber risk and all that, and you're done, good to go. All right? Obviously the managers are very happy."Oh, okay, I got my stuff signed off." Very happy."I made my KPI of the year." Wait till audit comes in, then you get screwed. Right? So I'm just discussing some of my own experiences in managing security in an organization, because these are realities. So when you're implementing ISO and all these things, don't forget to keep this consideration, because it may or it will come and bite your behind sometime in the future. Yeah, but you also highlighted the gap very clearly. The problem was obviously that there wasn't somebody present there who had the right kind of knowledge to make the decision. Because as board members... Put one in the board. Yeah, you see, to me, for example, if I'm in board right now, you come up to me with a policy document. The first thing I'll ask you is, "Has this been implemented?" Yes or no? Yes. Okay, then I'll sign off. No? Okay. The next question I ask is, "Do you have people to implement this?" Yes or no? Next question, "Have you secured the budget to implement this?" Yes or no? If you need budget, how much do you need? And the next thing I will look at the CEO is that,"Do we have budget to do this?" Obviously, the CEO is going to scratch his head because he'll say,"Why didn't you guys discuss with me earlier?" Right? So you get people like me in board. It's about putting the right kind of people in the board. It's about putting the right people in the board so that there is a holistic discussion where every single aspect is properly covered. Yes, but to be fair to board members, you only meet every quarter. You have so many things to discuss, so many areas to look at, which is why one of the things that I like about what Bank Negara did and also what MAS did is that they've insisted on having a separate board specifically looking at IT implementation, technology, cyber risk, so that you have the right people who can ask the right questions. Yes. So that when you get in, you know what you're getting out of it. Couldn't agree more. So that's a good progress, and I personally feel that a lot of organizations should look at either having this or having separate meetings specifically to cover the technological aspect of the organization. And that's very important. Because when you go into these things like ISO 27001 and all that, having that board visibility actually helps to show how serious you are as an organization to say that,"Yeah, we've done an ISO 27001. This is the result of the audit. We did fairly well in these areas. We still have a few areas that we're looking at. And then, you know, is there any shortcomings?" You can have the right kind of discussion that would set you in the right tone and send you to the right place. That's the part that we're actually alluding to. I fully agree with you. Wow, looks like we've covered quite a lot of things today. Yeah, and a very heated discussion about just policy documents, huh? We should probably look into this one a bit more. Actually, we should. It was a shock, you know? Yeah, yeah. Maybe we should just talk one episode just about policies, SOPs, guidelines, you know, and really dig deep into that. Because, I mean, it's something that all organizations have, but very few organizations actually get it right. And, you know, and it's an area that, you know, it can either make you or it can break you if it's not done properly. Fully agree. Alright, so… Both sides of the coin, they're equally important. Definitely. So, thanks for the wonderful discussion. I'll catch up with you soon in the next episode. Take care. Bye-bye. You too. Bye-bye. Thanks for joining us this week on Security Lah. Make sure to visit our website at securitylah.asia where you can subscribe to the show in iTunes, Spotify, or via RSS so you'll never miss a show.[music][music](gentle music)[BLANK_AUDIO]