Latest / Secure & Simple — Podcast for Consultants and CISOs on Cybersecurity Governance and Compliance / Best Practices for Writing Policies and Procedures | Interview with Carlos Cruz

Transcript

Best Practices for Writing Policies and Procedures | Interview with Carlos Cruz · Secure & Simple — Podcast for Consultants and CISOs on Cybersecurity Governance and Compliance

• 0:00
  Dejan Kosutic: Welcome to Secure and Simple podcast. In this podcast, we demystify cybersecurity governance compliance with various standards and regulations and other topics that are of interest for consultants, CISOs and other cybersecurity professionals. Hello. I'm Dejan Kosutic, the CEO at Advisera and the host of Secure and Simple podcast. Today, my guest is Carlos Cruz.
• 0:23
  He's the founder of consulting company called Metanoia based in Portugal and is also the main ISO 9,001 and ISO 14,001 expert in Advisera. Now he's in consulting business for thirty five years and has performed more than a 100 consulting jobs, close to 100 certification audits. So he has really lots and lots of experience with writing all kinds of documents. So in today's podcast, you'll learn what are the best practices to create and manage policies, procedures, plans, and other documents for ISO standards. And what you'll notice is that the best practices for nine thousand and one and fourteen thousand and one standards can also be applied to ISO nine ISO 27,001 or any other cybersecurity frameworks like NIS2 and DORA.
• 1:13
  Welcome back to the show, Carlos.
• 1:16
  Carlos Cruz: Thank you for having me. Thank you for the invitation.
• 1:19
  Dejan Kosutic: Yeah. Great to have So you back you were actually on the first episode of this podcast a while ago. So I'm really glad to have you back here. Great. So how many documents actually did you write in your career?
• 1:37
  Carlos Cruz: I don't know. I don't know. Thousands and thousands of, you know, procedures, work instructions, forms, checklists. Okay.
• 1:52
  Dejan Kosutic: Lots of experience, obviously. Great.
• 1:55
  Good. Now, let's dive into this topic of writing documents. So, there are different types of documents like policies, procedures, plans, these kind of things. So, in which situation actually do you normally How do you actually choose which type of a document you have to write in a particular situation for a client?
• 2:19
  Carlos Cruz: So for me, everything starts with making a high level view, okay? High level view, high level model of how the management system works, okay? So if I'm working with quality, so why do the mapping all the processes in the organization. Okay? That's the the start.
• 2:45
  But even if I'm doing 14,001, that's not so much process based, but I like to do this kind of big big map of how things will will work. Okay? So and from there, many many years ago I learned this way of thinking is there are some documents that just explain what do we do. Okay? So what we do, who is doing it and, okay, responsibilities, this kind of documents is what we normally call procedures.
• 3:25
  I don't use so much that language that is very common in certain countries like policies. Okay. I call it procedures. So this high level, so just saying what we do, who is responsible for doing or responsible authorities, collaboration. Okay, something like that.
• 3:46
  We have something when we need to explain, to go to the detail how to do it. So that's what others call what some call work instructions. So, but it's much more detailed, much more detailed kind of documents. Okay. So, and I try, it's a fight because in my mind I want to put everything in detail, but I realized after some years that that's not a good practice.
• 4:21
  So there's a fight in my head is that let's start with the most useful and simple document as a starter. Okay? So in some organizations we just do what I call these procedures can be just a flowchart. Okay? A flowchart with the description of the responsibilities, the purpose and things like that.
• 4:51
  Because I don't want us to waste not waste, but to use a lot of time in doing that. Because if we do that with if we use a lot of time in doing that, then we we become very tired for doing the the rest, the improvement phase. And so I I I like to keep it as doing that as fast as possible and as simple as possible. Later when we do internal audits or when we look into the performance results, we see that what needs to be could more meet there.
• 5:29
  Dejan Kosutic: Okay. So, basically, procedures are are documents where you describe, let's say, let's say, the major steps or major responsibilities, and, working instructions are, let's say, lower level documents where you actually describe in more details, maybe particular steps and so on. What are the Yes. Policies Sorry. Mhmm.
• 5:50
  Carlos Cruz: Yeah. Oh, can be so something very detailed or, for example, explain what is the rules for coding the lots in our company. So it's not specific step, but just saying, okay, we do things like this or this is the way we evaluate suppliers. It's like this.
• 6:14
  Dejan Kosutic: So this is for working instructions, but what are the policies then?
• 6:20
  Carlos Cruz: So, as I said, according to my experience, according to my history in doing this, don't normally work with that, what people call policies. What I do could be related with that is what we It's no longer mandatory, but I still like to write a quality manual. I like to call it the management system manual, okay? So a high level document where we explain perhaps let's say the policies for certain topics or we present the processes and we explain that these high level ideas about what we expect from the processes. So is it in plain English, in plain French or in plain Portuguese?
• 7:15
  Dejan Kosutic: Okay, great. Yeah, from my experience, let's say in cybersecurity, usually you write policies like, for example, a backup policy where you basically define some kind of an intent. Right? And then you say, okay. For these systems, the the backup will be done according to this frequency.
• 7:32
  And then you have a separate, let's say, backup procedure where you actually describe in more detail how you actually use particular systems to to do the backup. Right? So in my view, especially in cybersecurity, the the let's say, policy defines a more general intent, whereas procedure is more, let's say, detailed, describes the process or the steps actually how something is. So usually it's like this. And
• 7:59
  Carlos Cruz: there's one thing that I was missing, and you already mentioned that. So there's another kind of document is the plan. So like, so in quality is very, is something like, how do we plan to control the quality of our product in step one or step two or in the final step of our manufacturing or our service or how do in environment, how do we plan to monitor certain, so air emissions or the quality of the wastewater. So how many times, what kind of parameters, who will do it, where will be recorded, where, who will act based on the results. It's also very, very important.
• 8:49
  Okay. Very, very important.
• 8:51
  Dejan Kosutic: What is then the difference between a plan and these other documents like policies and procedures?
• 8:58
  Carlos Cruz: So the plan is, me, the plan is like, it's like a table. Okay. It's just a table, a very visual where we say, okay, for each column, we put things like what we want to or what we need to measure, when, so another column, when, we will do that, what are the specifications that will be recorded? So each one of these will be a different column and each row will be okay for each situation. Okay, we have this wastewater, amount of wastes, amount of quality of air or noise levels, things like that.
• 9:49
  Dejan Kosutic: Yeah, in my experience, let's say in cybersecurity, you have this risk treatment plan. Basically it describes how you're going to implement cybersecurity controls. And from that perspective, a plan is something that is, let's say, time limited or time bound, and it's specific for particular controls. So it's not like a general principles like a policy or or steps. It's more concrete.
• 10:10
  And it says, look. You're going to implement, I don't know, backup control until that time with this kind of resources, with this kind of responsibilities. So it's specific for a specific situation or process or control or whatever. So from cybersecurity, this could be, let's say, an approach to planning, right?
• 10:29
  Carlos Cruz: I would say when in 2015, the quality and environmental standards appeared with this version about the risk. At that time, in my mind, I was thinking something, this is much more easy to be applied by a company that is starting or their quality level is very, very low. They have nothing because they will, what they need to do is what you were saying. Doesn't matter if it is cybersecurity, it's the same. So what are the main risks for problems with our quality of raw materials, quality of during the steps in the manufacturing and in the final product.
• 11:20
  And based on that, we develop the quality control plan. What happens is that when a company in the quality field starts working with the standards, normally they already have a quality plan. Okay? So it didn't start based on a risk a risk treatment, but it should start with a risk treatment because it's it's it's like that. Yeah.
• 11:47
  Yeah. It's it's the basis is the same.
• 11:50
  Dejan Kosutic: Yeah. Okay. Now do you prefer, I would say, longer and more detailed documents or shorter and and, let's say, less detailed documents? What do you think is better?
• 12:03
  Carlos Cruz: I prefer shorter documents. Mhmm. And I learned with IT people. Okay? I learned with IT people some rules that I'm you know when I started and for some years I did what I normally see.
• 12:21
  Okay when people are writing a procedure they are writing a text. Okay a sentence and another dot, another another sentence, dot, another sentence. Then I I read a book. I don't have it here with me, but I have it in my office. I read a book where the the authors were saying write short sentences, okay, always starting with a verb.
• 12:49
  Mhmm. And and it's wow, it's it it makes the document much much focused. Okay? We we we in Portuguese, we say it's not a will, you know, right reading the will of the dead. No.
• 13:07
  It's very tack tack. You need to do this, this, and this, and it starts with a verb. So what needs to be done? This, this, this, this. Wow.
• 13:16
  Dejan Kosutic: Why do you think this is better?
• 13:18
  Carlos Cruz: Well, I like it. It's better because it it focuses people into what needs to be done. Okay? And there is no need for words connecting one part with the other and for people like me, if we don't have that kind of discipline, oh, we can, we don't need chatty pity, we can write and write and write a lot of things. The the important things or are buried in all that text.
• 13:58
  So yeah, I think short short documents, because if the document is very long, people will not read it. Okay? And now more and more people don't have documents in paper. So people have documents in tablets, in screens and so, and they must be, the most important must be in one or two screens. Okay?
• 14:28
  Yeah. One or two screens. If possible, just one screen.
• 14:32
  Dejan Kosutic: Yeah. Yeah. I agree fully with you. And and especially when working with smaller and perhaps mid sized companies, this is a better approach. However, what I found is when working working with larger organizations, especially financial institutions, these guys are typically used to actually having more detailed and lengthier documents.
• 14:52
  And especially when I worked with DORA, the cybersecurity regulation for financial institutions, I found actually that it's better for those, for this particular target audience to write lengthier documents because DORA in itself is very, very much detailed. It's very prescriptive. So to cover all of these requirements, you actually need to have larger documents. So in general short, yes, I agree with you, but for some cases it's actually longer, it might be better. What
• 15:20
  Carlos Cruz: I prefer to do is to have that high level document, very short, and then they are deployed into those more detailed other documents. So you can always start at the high level view and have the big picture and then going through those other more detailed, very specific. Yes, because sometimes there are things that we need to be So I work for example with pharmaceutical companies. Okay. So there are things that must be very clearly detailed there.
• 16:04
  Okay. What needs to be done, temperatures, pressures and okay. So, yeah, so yeah, but that's the we do this kind of deploying of
• 16:19
  Dejan Kosutic: the Yeah, yeah. So these detailed documents are probably these instructions that we discussed in the beginning. Do you typically prefer having more documents in company or less documents?
• 16:38
  Carlos Cruz: I prefer, because of what I was saying, I prefer more documents. So if they are shorter, more focused because they are I'll call about that. Because of that, so having more documents, but each document is much more focused. It's not like so my background is chemistry, you know, okay? And I always I think a lot of I use that image a lot of times is, you see, when we put, oil and water, they don't mix. Okay? And then we put soap.
• 17:19
  We normally, what I see in documents is a document is like a drop and then you have several, okay, several strings coming up from that center. So for example, for human resources, okay? You have one string is training. Another thing is onboarding. Another one is salaries.
• 17:44
  Another one is dismissing people. Okay. Everything is in a procedure about human resources. I don't like that. So I prefer, okay?
• 17:58
  I prefer, so seeing things as a sequence, as a process. So onboarding is one document, So very whenever they say, okay, we have an onboarding, someone is going to join the company. Okay, it's here, it's this. Or training, it's another one. Or salaries or
• 18:18
  Dejan Kosutic: Understood, yeah. But for smaller companies, how do they make sure that people are not overwhelmed by, let's say, a larger number of documents?
• 18:29
  Carlos Cruz: So the number is larger, but each document is very focused. It's just for that. And that's why the importance of having a high level document, so where you have a kind of the flow chart that explains that, that sends you to, okay, if you have doubts about this, go here. If you have doubts about this, go here. So it's not a problem because you may have very small number of document, but each document is very large.
• 19:18
  It's a a lot of pages or okay. Yeah. A lot of screens. And people needs to also being there looking for the right topic. So it's it's
• 19:28
  Dejan Kosutic: Yeah. So it's probably also an importance of of naming the documents so that from the name of the documents, it's clear who who the target audience is. Right? Because I don't know for these procedures for, I don't know, hiring and firing people, it's all obviously for HR department. So if it is clear what it is about, then it's clear that no one else should delete it, but except the HR employee.
• 19:50
  So I think it's about naming.
• 19:51
  Carlos Cruz: Yeah. Yeah. And you took That topic is very It's something that I like a lot and I learned also with guys from the IT is the way I try to name is not always possible. Way I try to name a document is a verb and a noun. Okay?
• 20:18
  And the trick is if you invert the the put the the the noun and then the name, you have the main deliverable of that topic. Like, for example, train people. People trained. It's the main deliverable. Okay?
• 20:40
  So it's also So the name is very important to be clear what is the topic that we are speaking about.
• 20:53
  Dejan Kosutic: In my experience, I actually try to, when working with smaller companies, to reduce the number of documents, even though the documents are already short. And then in this case, I sometimes actually tend to merge, let's say, policies and procedures. Again, going back to this backup example, there is this backup policy. If this is a smaller company, actually, I would write only the backup policy. I would not write the backup procedure because it's probably too much for a company of, let's say, 20 employees.
• 21:23
  So I would actually include in the backup policy also the, let's say, a process of handling backup so that they have one document, not two. But if this is a larger company, then I would separate backup policy from the backup procedure, where obviously the belt policy is more generic and procedure is more detailed. Now let's speak a little bit about structuring documents. So, in your experience, how do you normally structure? I mean, what are the, let's say, general sections that you usually include in your documents?
• 21:58
  Carlos Cruz: So, there are some things that are always there. So I like to start with the purpose of the document. So when I started at the beginning, I used to write objective. And then I realized that when we write objective, normally what people write is the objective of the document, or the purpose of the document. But no, that's not what want now.
• 22:29
  I want what's the purpose of the set of activities that we are describing in the document. Okay? And so that's why I always start with a purpose. Then with some companies, okay, because some companies like it, some companies don't like it. After that, we have what are the KPIs that will measure the performance of that process or okay.
• 23:05
  Then we may have what are the clauses of the standard that are related with what we are going to mention in that?
• 23:16
  Dejan Kosutic: So references, yes.
• 23:18
  Carlos Cruz: Then, yeah, yeah. Then kind of a matrix with the main steps and the responsibilities, authorities, kind of a rassey matrix. Okay. Yeah. And then comes the flowchart.
• 23:35
  And for me, the flowchart is very, very important. And then it's like this, as I was saying in the beginning, in some companies we stop there at the flowchart. And then, okay, we put something like, we put something like, or may put there something like, a matrix with the records. Okay? What are the records developed or related with that document?
• 24:02
  So and for some companies it's like that. For other companies we all after the flowchart we include the description. Okay, of the actual text describing.
• 24:19
  For me, in theory, it would be something like, I would always start with just the flowchart. And then when we measure and we look into performance of its results, we will realize, okay, there are here some documents where we need to be more detailed. Okay. Let's write the text after the flowchart. Okay?
• 24:40
  So so so that's for me for me that it's the best approach. Again, I want to reduce the amount of time that we use to develop the documents. Because I want to make people I want that people don't think that implementing a management system is just writing the documents. No. It's writing the documents, implementing, monitoring and improving.
• 25:13
  Okay? If I'm the consultant, if I if when I leave the company because they are certified, they already performed two or three iterations of improvement, it's very possible that without me, they already will continue that.
• 25:30
  Dejan Kosutic: Okay. We'll come to this sorry to interrupt you. We'll definitely come to this topic of, embedding this into the company, but let's first discuss this structure. I mean, try to come up, let's say, basically discuss this structure of the document. Mean, do you typically do So, you have, let's say, some sections that typically come at the end of the document?
• 25:58
  Carlos Cruz: Just that one that I mentioned, so the metrics, okay? The metrics of the record, so the rules to retain the record, okay? Remember, I mentioned at the beginning to put there the KPIs, okay? In some companies, we also include a plan for monitoring those KPIs. So the frequency we will monitor where they will be stored, but not in all companies.
• 26:32
  Not in all companies. So I kind of have the framework in my mind, I present to the companies. And so some companies accept, some companies don't accept. Okay, I understand because they may say, Oh, then if we need to change the frequency, there may be a chance that we forget to do that and then the document will be not updated. And so, okay, we need maybe better to have a a global plan where we put that.
• 27:02
  Okay. So it's yeah. Okay. Yeah. For me.
• 27:05
  Dejan Kosutic: Typically, I I put at the end of the documents, I put the document owner and the frequency of the review of the document because I find this that then it's much more clear who is in charge actually and how often they need to review this.
• 27:20
  Carlos Cruz: Okay. Sorry, because you're right. So in the first page, we have the identification of the kind of document and the title, the name of the document, like qualified supplier. Uh-huh. And then we have also okay.
• 27:45
  Okay. Related with the control clause 7.5 control of documents, we have something like Mhmm. The code, the identification of the document, the version of the document, sometimes the date of the document.
• 28:03
  When I work with pharmaceutical companies, it's funny because once I heard marketing guy saying that pharmaceutical companies always have a date with the graveyard because their best sellers at some point, they will lose the patent. They will not be protected by the patent and then the competition will start. And so it's funny because with some pharmaceutical companies, put there the last day that the document is updated to be sure that the document is not being used after some time. Because some are FDA approved and the FDA don't expect that they review. It's not review just checking, oh, does this document needs to be reviewed?
• 29:07
  No, no, no. We must. Even if we don't make any changes in the document, we must update the date and so on.
• 29:18
  Dejan Kosutic: Okay, so you can put the document owner and, let's say, review period and validity period also at the beginning in this, let's say, front page of a document, so that you don't actually put it at the end. So it's really up to each company to decide. And what I typically also do in the beginning of the document, I also put the purpose, but I also usually put the users and the scope because I want it to be clear what is basically the distribution list of this document. When I actually specify who the users are, and I don't mean names, I actually define what are the departments or let's say the roles that need to be informed because it's much easier than to distribute this document. So that this is why I I find this, let's say, users as as a useful one.
• 30:08
  And scope, I find it useful because then it's actually clear to everyone to which, let's say, departments or which processes or which technologies or whatever this document applies to. And by definition, then what it does not apply to. So I think it's easier for readers of the document to understand what is this this about?
• 30:34
  Carlos Cruz: Okay, so about that distribution, okay? So it's another, I follow a different approach. So what I have is, a plan where I list It's something that normally certification auditors ask is a list of all the documents that are relevant for the management system. So we have a list of all the documents. What's the current version?
• 31:10
  And we may use the same plan, okay? But we sometimes or most of the time, we separate because we don't want to send that part to certification auditors. But this to then have what you were saying, the distribution of the document. Yeah. Because we want to be sure that when a document is reviewed, this change the version is changed, we must be sure that the previous versions are destroyed or people are informed that the previous version is no longer is no longer in use and they are warned that we have a new version.
• 31:58
  Dejan Kosutic: Okay, but where do you normally then keep this distribution list? What is, let's say, the best practice in your opinion? So,
• 32:09
  Carlos Cruz: most of the companies use a kind of It's a table. So it's a plan where we put there. But it's in the computer file where have that list.
• 32:25
  Dejan Kosutic: Yes. Yes. Yes. But do you actually have it for each and every document separately, or is this a distribution for No. No.
• 32:31
  Carlos Cruz: No. It's it's for all documents.
• 32:34
  Dejan Kosutic: Yeah. But if you have a distribution list for all documents, it's not that every document needs to be read by everyone. I mean, this example for HR departments, it doesn't need to be read by the whole company, only the HR employees.
• 32:46
  Carlos Cruz: Yeah. Yeah. No, what's included in specified there is who has need to use this document. We need to have access to this document. It's there.
• 32:59
  Dejan Kosutic: Okay. So it's a different approach. So again, I prefer actually to have this written in document itself. Okay, obviously there are different approaches to this. How do you actually by the way, just to mention, you mentioned also that you have these flowcharts.
• 33:19
  Yeah, flowcharts are very useful, I think, for procedures. But for policies, probably not. Right? Because policies are not procedural It's It's It's so for for procedures. Yes.
• 33:32
  Okay. Now for documents, how do you actually ensure when you work with your clients? How do you ensure that this, what you're writing in the, let's say, procedure really reflects what is a current state of what the company is doing, right? Do you actually adapt these documents to be a right fit for a particular client?
• 33:57
  Carlos Cruz: Okay. One previous topic is that when I write these documents, I try to warn the company or the organization that we are not going to write how we want things to be done. We want to write how things are currently being done. Okay? So one thing is taking pictures like the old way of taking pictures.
• 34:30
  Okay? Another thing then is when we compare the actual picture with the requirement of the standard or with the results and we need to change, we need to improve, we need to make some changes here. That's another thing, okay? Because if we try to do both things, it's possible, but takes much more time, okay? So then what I do is I try to have an interview with relevant people that are doing what is being described in the document.
• 35:09
  So for example, if I'm doing a document about how to onboard people in the company, okay, so what I do is okay, so normally who is included in the onboarding process? Okay? We have someone, one or two persons in the human resources department. Okay? We may have one or we have the people that are the head of departments that will receive the new people, we'll have them So, okay, now, we have an interview with those people, so and they speak and they speak and I write, I make drawings, I try to collect that information.
• 36:02
  And then I think I have this technique described in that book, okay, about ISO, discovering ISO 9,001. But it's it's like then what I do is I use the highlighters, okay, colorful highlighters, and I'm going after the verb, you know, because the verbs will be the anchor points for then translating the conversation because normally people don't follow a chronological order. So someone will say, I will do this and this and this. Okay. Then another one will say, Oh, we also do this.
• 36:37
  We also do this. And then, okay, we need try to make, try to find the flow, how we do it as a flow.
• 36:48
  Dejan Kosutic: So the point is that you are adapting, let's say, this particular document to the specific, let's say, process that exists in a company. Right? And it was interesting that you were saying that actually you want to kind of write how it is, not how it might be in the future. Right? But sometimes actually the companies, when you tell them something like this, that they have to describe their existing processes, sometimes they say, okay, but how do we make sure that this will be compliant with the standard?
• 37:21
  How do we actually respond to, let's say, a question like this?
• 37:26
  Carlos Cruz: Okay. So first we describe what we are doing. We must have something palpable, something concrete. This is how we do it. Okay.
• 37:38
  And then we compare with the requirements of the standard. We need to do that kind of a gap analysis and to see okay are we doing is something missing here? Do we need to for example, for example, it's typical. Every company will say, oh, we do training. Oh, we train people.
• 38:03
  Yeah, we do training. And okay, and what kind of evaluation do? Oh, at the end, we ask people if the trainer was okay and the trainer will also evaluate. Okay, but, effectiveness of the training? How do you measure?
• 38:20
  Carlos, what do you mean with that? Okay, so we don't do it. Okay. Right? Or yeah, so it's an example.
• 38:28
  So, okay, we need to change this. Okay. We need to include this. But yeah, we need to do that because there are things that companies so there are some areas in companies that we can say for example for quality in the commercial department. Almost the companies do comply with the requirements of the standard, okay?
• 38:55
  But for example they may not do they may not evaluate customer satisfaction, for example. Okay. Okay. So how do you want to evaluate customer satisfaction? There's this possibility, there's possibility, there's possibility.
• 39:14
  Oh Carlos, what is your opinion? Okay, this one has this pros and cons, this one is pros and cons. Okay, my opinion, I prefer, I think that it will be better for you if you follow this approach.
• 39:32
  Dejan Kosutic: What do you think, how useful actually is it to use some kind of templates when you are working on documents for a company?
• 39:41
  Carlos Cruz: Okay. Glad you asked that because there are situations where I think templates are useful. Okay? So things like internal audits.
• 40:00
  We don't need to invent a wheel. It's something that we can use the skeleton is similar for any company. Okay. Then the company may have different requirements for auditors and so different, but okay, for internal audits, for corrective actions, okay, even for example, things like, complaints, so at least as a starter, okay, as a starter. So these are dosage, these are doc For example, document control.
• 40:44
  Okay, so yeah, things like that. I think templates are useful, Okay? Templates are useful. Oh, if so all the so if I was thinking in terms I'm sorry, this is just more for people that work with 9,001. So topics that are in clause eight, I try to be as more specific with the company as possible.
• 41:12
  But other topics like about the maintenance clause seven or training or clause nine monitoring or or management review, we can use templates.
• 41:26
  Because it's something that is more high level. So Yeah. For environmental management systems, I think we can even use more templates, okay? Because it's not something that is very, again, clause eight, so what are the operational control or the emergency situation? That's more specific of each organization.
• 41:51
  But how do you determine, evaluate environmental aspects? That can be risks, but also What
• 42:06
  Dejan Kosutic: we've actually found is that there are some, let's say, crucial things that companies need to adapt these documents for their specific needs. And, usually, it comes down actually to three things. This is a people, processes, and technology. When you think about it, you know, these people, processes, and technology are actually at the core of of organizational kind of behavior. Right?
• 42:31
  And then, basically, when you create these templates as part of our toolkits, we always make these templates in a way that we actually enable our our clients to change, well, people meaning roles, the processes meaning the steps, and technology if if they're using some technology for a particular, process. And in that way, by actually, asking them to insert their own people and processes and technology, basically enable them to adapt this document for their specific needs. So I find this approach of people processing technologies as a concept of actually adapting documents the best way.
• 43:11
  Carlos Cruz: Okay. Yeah, for example, the people, yeah, companies, you know, different companies, so the scope of responsibilities, it depends on tradition in each company, depends on tradition. So the same name for function in one company and then another company, they may have the same name for the function, but the scope of activities, the responsibilities and the authorities are very, very different. So, yeah, yeah, yeah. That's one.
• 43:50
  Yeah. And also, yeah, the technology. Yeah. The technology is is yeah. Yeah.
• 44:00
  Dejan Kosutic: I mean, ISO standards specify which documents are mandatory and and basically it it makes it clear in the standard. It says, you know, this shall be documented or shall have documented information. So it's clear. Actually, it's easy to understand from the standard itself what is mandatory to be written down. But most of the things, most of the policies and procedures are not mandatory.
• 44:25
  So how do you actually decide or how do you recommend to your clients what to write down even if it is not mandatory?
• 44:37
  Carlos Cruz: So, as I said in the beginning, we do that kind of mapping, global mapping. So the model of how the management system works. So we determine what are the processes And then I say that each process needs to be described, how are we working each process. And so I want them to describe the the how each process works. We can do we can do we can use one document to describe two processes or we can use or we can describe process in two or more documents.
• 45:24
  That's not that's that will depend. Okay? But the that level of what needs to be what needs to be done, the what, the who, and the when, it's always written. Okay? It's always written.
• 45:45
  It's not mandatory, but Okay. But this is
• 45:52
  Dejan Kosutic: actually the point, you know. Let's say that a company has, I don't know, 50 processes and it's a very small company. It's not going to document all of them because only, I don't know, five of these 50 might be important. So how do actually decide?
• 46:07
  How do you decide which will be documented and which not?
• 46:08
  Carlos Cruz: Yeah, it's the relevance of the set of activities in that process. For many years, I used the example of snail mail, so the old mail. So we may write a sequence of activities, a process, a flowchart about how to handle mail in our company. Does that mean that will we do it in our management system? No.
• 46:43
  Most of the time, no. But if our company is a company selling by catalog and receiving orders by email and by mail, of course we need to translate that into a process. It's relevant. It's about thinking about the importance of the topic for the scope of the management system. So for example, there's a clause in in the quality standard about maintenance.
• 47:16
  Okay? And there are some organizations, or I would say 50 of the organizations I work with, that we have a procedure about maintenance. But the other 50%, we don't have a procedure because it may be a work instruction connected to the manufacturing because it's something very simple, very easy, something that they will do in the August, the plant is closed and someone is there, during the general maintenance. So it is something that is really relevant for the management system objectives. It's something that, because of what we are doing there, we have some issues in the performance of the management system.
• 48:05
  No, no. Okay. So we don't need.
• 48:07
  Dejan Kosutic: Yeah, yeah. Yeah. In cybersecurity And
• 48:10
  Carlos Cruz: we may update that decision, okay, based on monitoring results and audit results. We may update that decision.
• 48:18
  Dejan Kosutic: In cybersecurity, basically we use usually the, I mean, concept of importance is basically the concept of risks, right? So the higher the risks, the more likely you will write the document because it needs to cover these risks. You want to make sure that you actually have a documented process to to cover the highest risks. Right? So the risks are usually one criteria, but another criteria might actually be the number of people involved.
• 48:44
  Because if you have, let's say, three people involved, you might not need the document because if these three people are sitting in the same room and they know each other very well, they probably don't need the document. But if there are 300 people involved in the process, you probably need to write it down because otherwise, how will we make sure that all of them will will follow the same process. Right?
• 49:05
  Or if you go actually to the other extreme and have only one person doing a a a process, you will also probably need to document it because if this person goes away, then you need actually someone else to take over this process, And then actually, should document it because it's only one person who knows it. Right? So Yeah. In these extremes, you know, very few or or very large number of people, then usually you should document it. Whereas if you have a moderate number of people, you won't document them.
• 49:35
  Carlos Cruz: Yes. And also, if there's high turnaround of people, so people are always coming in, coming out, going out of the company, so, okay, that means that, okay, we need something table, okay, a document is necessary for that situation. Yeah. Okay. One thing is we are mentioning here documents.
• 50:02
  So we are mentioning here and we're mentioning writing. So things like, and we think about procedures in terms of screens or in terms of paper, but can be a video. Okay. Can be a video. We can use a video.
• 50:22
  Dejan Kosutic: Can you give some examples of a video procedure in a company?
• 50:28
  Carlos Cruz: So video, for example, environmental management system, so to good practices in separating the different kind of wastes, okay? Segregation of wastes could be an example. Another example could be, so many, many years ago, I had an experience with a company, they were manufacturing pine furniture. Okay. And they say, okay, you know, in pine furniture, in pine tables, will find there some black or not black, it's brown spots, okay?
• 51:17
  And we call nodes, In Portuguese, we call it nodes. And we say, okay, if the node if we find a wood with a node, we cannot use it. And I was checking in the company. Oh, but that table, that wood there, you are using it and there's a node there. Oh, it's very small.
• 51:40
  Oh, okay. So we can use also this kind of videos for decisions, for these controlled decisions, for explaining what is okay and what is not okay. Many years ago, I worked with a Japanese company in the automotive industry. They were manufacturing wire harnesses for cars and they were incredible with the kind of the displays and using pictures to show different kinds of errors with components that they were receiving, the the border between what is acceptable and not acceptable. So they used now it's very easy to use videos.
• 52:19
  Yeah. But okay. The picture is also yeah.
• 52:21
  Dejan Kosutic: It's very interesting. And you also mentioned of course digital documents but also paper documents. Now in my world, cybersecurity digital documents are basically 99.9%. But in what cases are companies using paper based documents?
• 52:39
  Carlos Cruz: Yeah. I had an experience recently where I was saying, okay, nowadays no one use paper. You know, here in Portugal and Spain, two months ago, we had a blackout, energy blackout. Okay? So for about twelve, thirteen hours, there was no energy, zero.
• 53:04
  And you're saying, okay, there are some documents. Okay. That even if we have, there are some documents that we need to have access to those documents even during the blackout. If it's on a screen, okay, and if the screen is in a computer, the computer may have no battery, the battery may go down and so if we need in an emergency, if we need to have access to a document, It's important to have somewhere a paper version.
• 53:45
  Dejan Kosutic: Yeah. In cybersecurity, basically, we have this concept business continuity, right? And in, let's say, many cases, companies do actually print out their business continuity and disaster recovery plans on paper because of exactly what you were describing. Even though, you know, I would argue that even in such cases of blackouts, you know, if you actually download, of course, upfront, if you download all of these plans to your smartphones, you'll probably have them, you know, for a couple of days still even if they in the blackout. So, yes, paper documents for disaster recovery, business continuity, but, yeah, you have to just simply assess the kind of risk of actually having this downloaded on your smartphone.
• 54:36
  Carlos Cruz: Course, if we don't use paper, it's control, it's easier, okay? At least, okay, it's easier keeping the current versions, the distribution and so on, so it's much easier.
• 54:53
  Dejan Kosutic: And cheaper, yeah.
• 54:54
  Carlos Cruz: Much easier.
• 54:57
  And also, you know, once I was doing a certification audit, it was a company, a construction company. They were about thirty thirty people in the company because they were manufacturing high quality concrete. And they had everything on paper. They have 29 versions of a procedure. And in my mind, I remember that.
• 55:22
  So I started thinking, no one wants to make any changes in this system because each each change will represent, 29 copies of a document, each document had around five pages. So five pages times 29. No. Okay. So no, this is fantastic for crystallizing.
• 55:53
  A management system because no one wants to make changes because it's expensive, it's intensive.
• 56:04
  Dejan Kosutic: Yeah. Yeah. And actually, if I can mention also on this on this paper versus electronic, you know, all these, you know, tech companies that that I typically work with, you know, and they say, no, no, we don't have any paper documents. None. And then I asked them, okay, And you do have to protect paper as well.
• 56:36
  But okay, anyway, in your experience, who is the one actually to write all of these policies and procedures?
• 56:45
  Carlos Cruz: So, in my projects, in the projects that I participate, okay, so my approach is I write the first version. Okay? And there are interactions, so I write the first version, I send to the company, the company corrects reviews. And as soon as they say, okay, it's okay to we have the first version after that, okay, all the changes, all the control is up to them. But the first version is I write it.
• 57:27
  Dejan Kosutic: But why not?
• 57:29
  Carlos Cruz: We can follow other approaches.
• 57:31
  Dejan Kosutic: Yeah. But why do you think that a consultant or why in your case, you wouldn't write a subsequent versions? Why not adapting these documents further for our clients?
• 57:43
  Carlos Cruz: No, because I want them to learn to do that. I want to take the responsibility for doing that. Okay, everything Okay. So we have the first version, the person responsible for that document made a final approval. Okay.
• 58:02
  Now the document is yours. Now it's up to you, the control. Even if next month I will do an audit, or someone does an audit and they, okay, realize that we need to make some changes here in the document, okay, I will check if they are doing the changes, if they are doing document and the changes are being done according to the procedure, but I'm not the one doing that because I want them to learn that.
• 58:30
  Dejan Kosutic: Okay, to maintain it. So when you say that you are doing the first version of the document, are you saying that the first draft version or the first approved version of the document?
• 58:43
  Carlos Cruz: Until the first approval of the document. So the first draft, I send the first draft to the persons involved. They make changes, they correct, they ask questions and we fine tune and then, okay, they send to me. Okay, I make another version.
• 59:00
  Dejan Kosutic: I understand.
• 59:00
  Carlos Cruz: Okay. So we are still in version 0.1, zero two, 0.3. When we go to one point zero, now it's yours.
• 59:15
  Dejan Kosutic: Okay.
• 59:15
  Carlos Cruz: Now it's yours. It's up to you. Okay? Because I want them to to have the experience of controlling. It's because if we if they only start doing that when I'm going out, when I leave the the company because the project is is done, they will have difficulties in doing that or more difficulties in doing that.
• 59:38
  Dejan Kosutic: And how does this document, the review of the document work? So basically you write the first draft and then send to a couple of people in the company. Who do you normally send this document to for review?
• 59:55
  Carlos Cruz: I send to one or two persons, so the one or two persons that were present in that meeting. Mhmm. Okay? Sometimes I that will depend. Sometimes I'll send also to the response of lots of documents because sometimes so some companies we have I I recently had an experience with heads of departments in a company Mhmm.
• 1:00:26
  That it was a pleasure to work with them. Mhmm. Because they had their they had their jobs. They had a lot of things to do, but but they took this seriously. And so they were they they they find they they they consider their responsibility also to check the to check the document to make their their their comments on the document.
• 1:00:49
  So so one or two people that were present in the interview. Okay? So okay. I sent for get that sometimes, okay, to the heads of the department, so they're responsible, that kind of document. Yeah.
• 1:01:05
  Some organizations, what they do is that upfront, they determine a kind of number, one or two, three people that will be responsible for the final approval before the COO approves the document. Okay? It's not mandatory to the COO to approve all documents, but there are companies that decide that the CEO will approve all documents. So they decide that, okay, there will be a team of one or two or three people that will check that document before the CEO.
• 1:01:43
  Dejan Kosutic: Okay. And with approval, if this is not a CEO, I mean, else could approve this kind of documents? I mean, make a final approval for a document You to be
• 1:01:58
  Carlos Cruz: mentioned the responsible for the document. They're responsible for the document. And for example, when we speak about processes and the process is trans departmental, that person is very important because it's someone that belongs to a department, but will have responsibilities over more than one department when we think in terms of trans departmental. So it's very, very, very important. And so that person is normally the person that approves the document.
• 1:02:41
  Dejan Kosutic: Okay. But how can a company decide whether a CEO should approve a document or someone below the CEO can approve the document? So how do they make this decision between these two options?
• 1:02:55
  Carlos Cruz: So there will clause 5.1 of the management system standards about the management responsibility. So one member of the top management, at least one member of the top management will be the main responsible for the management system. And that, if there's only one, okay, that one in some document, maybe a meeting minute, maybe a procedure, will say, who has the authority to approve what kind of document? Okay? It's a kind of having a chain of authority.
• 1:03:38
  Okay? We want to have that chain of authority that starts at the top management and goes up to, if we decide that some kind of forms can be approved by a supervisor. Okay. So the supervisor has authority to make changes to that document and approve the changes.
• 1:04:01
  Dejan Kosutic: Yeah. Okay. In my experience, usually it's depending on actually who document refer to or basically who are the users of the document. So for example, if this is, I don't know, for example, a backup policy that refers only to IT department, then typically this can be approved by the head of IT because it's only related to processes and technologies and people within IT department. But if this is a document like access control policy, which covers everyone in the company, then it has to be someone from the top, like CEO, maybe CTO, because it's not only for the IT department, it's also for all the other departments.
• 1:04:42
  So basically, when you think about it as organizational structure, as long as actually the users are below some person, then this person can actually approve the documents.
• 1:04:54
  Carlos Cruz: I agree with you 100%, but in some companies, there's someone in the top management that wants to approve everything.
• 1:05:05
  Dejan Kosutic: No, no, fine. Course, yeah. For smaller companies,
• 1:05:08
  Carlos Cruz: don't this is usually the like that because it will make things much less dynamic, Okay? But I'm just the consultant.
• 1:05:21
  Dejan Kosutic: Now, we also spoke about this document owner. So this is not mandatory, right? The standard does not require to nominate an owner of the document. Do you typically recommend this to your clients?
• 1:05:39
  Carlos Cruz: Yeah, I didn't mention that. You mentioned that, it was my mistake because I always include that. Okay? I always include the responsible for that document. And if the document is a document that describes a process, yeah, it's very, very important.
• 1:05:59
  Because, if it's a document related just with a particular department, we all all almost it's almost automatic or it will be the head of department. But but sometimes, okay, we have documents that describe things that start that oh, that start in one department, go to another department, and then go to another department. Who is the is the responsible, the main responsible for this process? Okay? Okay, who is the main responsible?
• 1:06:31
  It's very important to be clear who has the authority. Okay? Who has the authority? Because normally that person is also the person that will do the final approval of what KPIs to use.
• 1:06:49
  What KPIs to use. And it will be the person that will make the proposal for top management about the targets for each KPI. So it's really important. It's really, really important. So for me, it's not in the standard, but for me, it's mandatory.
• 1:07:11
  Dejan Kosutic: Yeah. Yeah. And this person also should be in charge of updating the document as needed, right? Least
• 1:07:24
  Carlos Cruz: review it. Then the nitty gritty can be someone that is responsible for clause 7.5, but the person that commands that no one can make changes to the document without the approval of that person.
• 1:07:39
  Dejan Kosutic: Of this person, yeah. And so, in your view, how often should the document be reviewed? So is this like every month or, I don't know, every six months or every twelve months? What is the best practice?
• 1:07:54
  Carlos Cruz: It's quality, okay? There's no For most of the economic sectors, okay? And for quality management systems, there's no mandatory frequency or period for doing that, okay? But I think that at least annually, someone making even if we don't change the document, but someone writing in a in a meeting minutes writing decision that we need to change this document or that document or we don't need to change the documents or these documents because of this or this or that. So, yeah.
• 1:08:47
  Okay. But there are, there are some, are some Okay. We are speaking here in terms of the internal documents of the organization. Because there are also the external documents like regulation, legislation that may have changes and we need to be aware of those changes to see if they imply any changes in our own documents and objectives. Yeah, annually least consider, do we need to make any changes?
• 1:09:25
  Yeah. And this can be related. I think this can be related with updating your risk. Okay? Because we also in quality and environment, we need also to determine risks and evaluate them and see if we I understand.
• 1:09:42
  Because if we have a procedure, if we have a process with a bad performance, that may mean that we need to change something in the document. Not because we want, but because the performance, the actual performance is telling us there is here a problem.
• 1:10:01
  Dejan Kosutic: Yeah. And basically the higher the risks, typically the more often you will want to review the process or the document that regulates it. So it could be also the I agree in most cases at twelve months will probably be a good period of reviewing documents. Now, typically when you introduce a new document in company, typically you would get resistance from at least part of the employees. And how do you normally deal with it?
• 1:10:36
  Carlos Cruz: We start during the writing of the document. Okay? So when we start writing the document, the idea is, so if we are just describing what people are doing and what people are doing, it's okay according to the standard, the requirements of the standard, There's no problem. We are just taking pictures. But if we need to make some changes and relating with information security would be something like we are checking what how do an organization starts working with suppliers.
• 1:11:19
  Okay? And okay. Oh, well, suppliers work with sensitive information and you don't have any commitment from their side regarding the confidentiality and so we need to do something, okay? And in those kinds of situations, so we want to introduce something new because it's a requirement in the standard and the company is not using or it's because it's a good practice that the company is not following. My approach is going back to, again, to that that people those people, okay, that we we interviewed and saying, okay.
• 1:12:01
  We have this problem. Mhmm. Okay? The standard says this. The standard says we need to to have some some we need we need to to we need this, but the the standard doesn't say how to do it.
• 1:12:19
  How can we do it? So I start there. I start asking their inputs because, if they if we follow the if they're if they have good inputs and if we follow their inputs, most of the resistance will be gone. Mhmm. Okay?
• 1:12:37
  Most of the resistance resistance will will be be gone. Gone. But okay. So now we e we included though their suggestions in the document. Now we have changes.
• 1:12:48
  So next is the introduction of the document, explaining why we are doing this. It's not because the consultant or the head of the department wants this. It's because of this situation, this problem. I like to show examples. Okay.
• 1:13:09
  I like to show examples of other, what happened with other companies. Okay. To show that this is not something, okay, theory. No, it's happened. They had this kind of problem.
• 1:13:21
  So there's a reason for doing this. Okay? So we can show them the pain, the actual pain for the organization or what can be the benefits for them if we make this kind of change? Then training, so if there are any changes, okay, okay, then training and then, okay, we start, we launch the procedure and then the idea is to have one month, four weeks after having a very small audit just to check if because, you know, when we are seated in a desk or at the table, everything is easy. But now when there's the contact with reality, does the procedure it's really works or we need to make some changes because, okay, the shock with the reality is is the final test.
• 1:14:23
  So that's how how I tried to do that.
• 1:14:29
  Dejan Kosutic: Oh, I like this approach a lot. Basically, there there are four elements to it. So as you were saying, first, getting the the insight and inputs from them. Second, actually raising awareness. Third, training.
• 1:14:39
  And then after the the launch of the procedure of the document, you actually get this kind of improvement phase and and making sure that all the, let's say, things that were not working well are are working that are improved. So, yeah, I I like this approach a lot, and I think, yes, this will resolve a large majority of resistance from anyone. And what do you think are the most common mistakes that companies or consultants actually make when writing documentation?
• 1:15:17
  Carlos Cruz: So this is my opinion, okay? So I think it's many, many documents. Okay? A lot of documents, writing a lot of documents, writing very detailed documents and taking a lot of time to develop those documents. And don't want to be nasty, but okay.
• 1:15:53
  Sometimes, I think that sometimes, we consultants want to develop a lot of documents because if we show a lot of documents to the company, the company say, Oh, okay, okay, my money is there. Okay, no problem. So, okay. But the point is So the point is, as I said, I'm repeating myself, but we need to develop those documents, not because they are mandatory, no, but because we need some kind of we need some stable version of how we do things in the company. And I don't want to take a lot of time in doing that, because I want to have time and fresh minds for doing the improvement.
• 1:16:49
  Because if we want to do the PDCA cycle, so if we don't close the PDCA cycle, because we took a lot of time in doing documents, the time for implementing the management system is gone and now, okay, they have the certification audit, they pass, okay, and that's it. But how many iteration cycles in the PDCA cycle we did together? 0.8, one. 0.7. So this the improvement will not will not work there.
• 1:17:31
  So and yeah. The the less time we use there, the the the sharper the mind will be for the the those iterations.
• 1:17:44
  Those iterations.
• 1:17:45
  Dejan Kosutic: I agree with you fully. I mean, companies very often think that the more documents they write, they will be more compliant. Whereas actually the opposite is true. Right? Because this overhead is only stopping them and killing them really, their operations.
• 1:17:59
  And as you were saying, it's killing their learning process. So I agree with you fully. This is probably the biggest mistake.
• 1:18:07
  Carlos Cruz: Now I will put my hat of, auditor and as auditor, I read a procedure, very weird, okay, with very demanding requirements, internal requirements And I say to them, okay, but you are not following this, but I'm just the auditor. You are the specialist and you say that in your organization, this must be done, but you are not doing it. So it's a nonconformity. It's not in the standard, but it's in your procedure. So beware of what you are writing.
• 1:18:46
  Dejan Kosutic: Yeah, yeah, yeah. Exactly. Okay. So we had a very lengthy discussion today and actually we spoke only about writing documents. So we didn't speak at all about controlling documents, and this might actually be a topic for for another episode.
• 1:19:02
  But let's wrap up the the the this episode today. So what would be your, let's say, top suggestions on how companies or consultants should actually write the documents?
• 1:19:17
  Carlos Cruz: So start with a template, okay? A structure that you can use, okay? Template, I use, so for some topics, as I mentioned, like internal audits, corrective action, some topics you can use from company to company or as a starter, okay, then they can customize, okay, but yeah. Use Work with people that are doing the job. So interview them in order to then take notes, translate that into short phrases starting with a verb.
• 1:20:06
  That would be a good starter for developing the documents based on what are is currently do being done. My experience is I don't like to mix. Okay? One thing is taking picture what is being done. Another thing is improving.
• 1:20:23
  I don't like to mix the two because it will take much more time. Be careful with the implementation. So prepare the implementation. There's a German consultant, not in quality, but that says that there's no resistance to change. What happens is that people are not well informed, not prepared for the change and they act, they respond normally because of that.
• 1:20:54
  Okay. So what we see as resistance is a lack of preparation for the change. Okay. Not informing, not including, not training. Yeah, I think it's, yeah, like you.
• 1:21:14
  Dejan Kosutic: Okay, great. Thank you for these insights, Carlos. And it's been a pleasure discussing this topic to you.
• 1:21:20
  Carlos Cruz: Yeah, pleasure. Yes. It was a pleasure also for my side. Yeah. Yeah.
• 1:21:28
  Dejan Kosutic: Great. And thank you everyone for listening or watching this podcast and see you again in two weeks time in a new episode of Secure and Simple podcast.
• 1:21:39
  Thanks for making it this far in today's episode of Secure and Simple podcast. Here's some useful info for consultants and other professionals who do cybersecurity governance and compliance for a living. On Advisera website you can check out various tools that can help your business.
• 1:21:57
  For example Conformio software enables you to streamline and scale ISO 27,001 implementation and maintenance for your clients. The white label documentation toolkits for NIS two, DORA, ISO 27,001 and other ISO standards enable you to create all the required documents for your clients. Accredited Lead auditor and Lead implementer courses for various standards and frameworks enable you to show your expertise to potential clients. And a learning management system called Company Training Academy with numerous videos for NIS2, DORA, ISO 27,001 and other frameworks enable you to organize training and awareness programs for your clients workforce. Check out the links in the description below for more information.
• 1:22:45
  If you like this podcast, please give it a thumbs up, it helps us with better ranking and I would also appreciate if you share it with your colleagues. That's it for today, stay safe!