ISO 27001 Certification: What Will the Auditor Look For? | Interview with Aron Lange

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 Aron Lange, and he's the founder of GRC Lab, and he works as a consultant trainer and a certification auditor for cybersecurity and specifically for ISO 27,001 and some other standards. And he also works as a certification auditor for TUV or TÜV SÜD certification body and has already performed couple of dozen certification audits for 27,001 and has recently also started to to do certification audits for ISO twenty seven seven zero one. So in today's podcast, you'll learn what is it that certification auditors are looking for when they perform certification audits.

So, welcome to the show, Aron. Hey, Dejan. Thank you so much for having me. Great to have you here.

So, what are actually from our experience, what are the most common nonperformances that auditors find when they do ISO 27,000 certification audits? Well, that's a great question. I mean, I think first of all, of course, it depends. You can't say it's always the same, but there are certain some, certainly especially when you encounter companies that undergo the certification process for the first time.

I'd say something that you typically stumble upon is findings related to the risk assessment or to the risk treatment, which is a mandatory part of the ISO 27,001 standard. So there is a requirement towards creating a risk treatment plan. And many organizations mistake or confuse what this is all about or they just don't really comprehend what is expected of them. So typically in a stage one audit, you see they have put a lot of measures in place and they have even spent money to acquire systems, set up complex processes, and it's it's all good on first sight.

But there's, like, no no no plan for this. It's not clear who did all that, what was planned, what is still coming, what was already ticked off, and what's the status of all of this. So they tend to get into the action without actually developing a plan. So that's something that's very common in a stage one to observe.

And if you are getting to that point, what is really typical to miss out in a first certification audit is you need to get two acceptances or two approvals. You need to get an approval for your risk treatment plan, which is often omitted. You need acceptance for the residual risks. Those two things that I just mentioned are something that I can almost bet on if I get to a stage one audit that this will be a finding.

It's like almost every time it's almost there. Okay, it's very interesting. Okay, and besides this, let's say, risk management, is there anything else that you find kind of common between most companies that you audit? I mean, it's like the classic finding.

So you have a policy that was established, but it was not established by top management, or at least they cannot prove or demonstrate that it was actually approved by them and not just written by their CISO or their quality management delegate or something like that, if you think about other standards. That's very typical. The scope is also something worthwhile to discuss. I mean, the scope typically does a great job at listing what's inside of the scope of the management system, the so called boundaries of the management system is often not really present or described in a in a good way.

So that's often overlooked. So typically, it's, like, in the details, I would say, about these findings. Yeah, it's very interesting actually to know this because companies can now prepare much better, I would say, and pay more attention to these things. Okay, and how do you actually find evidence?

So I believe our audience is very much interested in, you know, how do you as an auditor find evidence, find things that are good or bad in those companies that you are auditing? Well, first thing to do in an audit is of course to ask a question and then to listen. I feel like in an audit, it's very important that you allow your auditee to tell a story. I know there are some auditors that are maybe less experienced or that have, like, another approach towards that, but I feel like it always makes sense to connect certain topics with each other.

So allow them to start with something and then to tell along that story. If you think about risk management, for example, when you enter that discussion, I would always start with: Hey, explain to me what does your process look like? How do you assess risks? What does it look like?

Who's responsible for that? And then get an explanation about what it's supposed to look like. Once you have a picture and you feel like, well, the approach looks good and it's compliant with what the requirements are, you then get into the execution. And now you allow them to demonstrate that what they have defined on paper is actually carried out in practice.

And this allows you to get an understanding of what good or correct looks like, and then you can verify if they are actually doing what they're preaching, if you will. So basically you perform interviews with employees of the company, right? But what about other, let's say, ways of collecting evidence? What about collecting records?

What about personal observations? So what would you say is the, let's say, balance between different methods of collecting evidence? Well, know about some auditors that request certain documentation beforehand. So they request, for example, policies, records and procedures to study before entering the audit.

And then they use that as a baseline, as a guidance technically to lead the interview, to already know what this is all about. Some certification bodies do that, some auditors do that. And besides that, some auditors might even get access to systems to make an assessment for themselves. But this is something that is really rare and even for security and compliance reasons, I would never want to be granted right permissions an operating system of a client.

So I would always observe, look over the shoulder and make someone show me what's actually going on and never touch a system by myself. Yep. Yeah. Well, I'm asking you this because, you know, lots of people actually that are I mean, of companies that are implementing ISO 27,001, they think that actually the most important evidences are actually written evidence.

I mean, records and these kind of things. Of course, they are important, but are they really the most important? And and is this really I mean, from your perspective as an auditor, is this really something that you focus on the most or or is this written, let's say, verbal interviews that you're doing more important for you as an auditor? I mean, for me, the most important part of an audit is the proof or the evidence that what you write in your policy is actually carried out in practice.

So, I mean, the policy is nice. You have all these rules and these, let's say, intentions and objectives that you want your organization to follow. But is it actually manageable? Like, do you really do what you want them to do?

And so for me, a policy is maybe 10. But the execution and the evidence that what you intend to do is actually carried out in practice. This is the most important part for me. So to be honest, I don't give a lot about the policies, but they are like my guidance.

So I read what's there and then: Can you show me the evidence that here, you require encryption of hard disks? How do you enforce it? Can we be sure that all endpoints are actually encrypted? How do you handle that?

And then things start to get interesting and then you can see if this is just a mere, let's say, intentional result or desired result that they describe, or if it's actually lived in practice. Yeah, yeah. Basically, you know, it's because, again, companies that are implementing the standard are thinking, The only thing that that we need to do is produce, you know, written, you know, records of some kind. Yeah.

But from what you're saying is that this this, let's say, interview part also plays a very big role when doing the audit, right? So it's not like you're only digging, you as an auditor are not only digging through the records, right? You are also interviewing these Yeah. Again, basically for you to confirm actually that they do activities, is this enough actually for you to get some kind of a verbal confirmation or you also always want to see a written evidence of something that is being performed?

What is your approach here? That's a great question. I mean, as an auditor, I have to gather and collect objective evidence. So a mere statement that is verbally expressed is nothing that you can add to the audit report or use as a sample.

So when they tell you something, they always have to back it with objective, verifiable evidence. Right? Otherwise, it's not really usable as a sample or as an as an evidence for the audit report. But what I'm trying to kind of understand here is the only objective will objectively verify the evidence.

Is it only a written evidence or could it be also some other type of, let's say, evidence which is not written? Well, absolutely. Written evidence in the form of a policy is definitely a piece of evidence. Whereas if you think about the physical security of a client, you visit a premise and when you check is the door locked, Is there really an uninterruptible power supply as stated in the policy or as required by organizational standards?

Is there awareness for this topic? So if you make a walk through in a factory, I mean, approach someone and ask them, hey, do you know whether whether whether policy is published or do you know how to handle that? Do you know how to report an incident? Right?

So is is there awareness? Like, are people knowing what they're talking about? That's also part of the evidence and part of the overall impression that you have to gather as an auditor. I fully agree with you.

It's always a kind of a balance between these written evidence and observation of an auditor and sometimes, you know, the general awareness of people, of all of these things together, these things together, all of these evidence together is very often the clear indication that the company is doing something right. And to push this argument further, there are many, I would say, tool providers, I mean, software providers in the market which focus only on collecting the written evidence, right?

So what is your opinion? Is this kind of approach enough or is it okay where actually the tool actually collects only the written evidence but it doesn't really help with these other types of evidences? So what is your opinion there? I mean, I guess you can expect the answer.

Obviously, it's not enough to provide that. But maybe to better understand that, I think the tools that we all have in mind, most of them have a SOC two background. So they started to solve SOC two for service providers, for service companies in the past. And, I mean, since I'm not a certified public accountant, I've never been able to conduct these assessments.

But from what I hear and from what I observed as a consultant, like sitting on the other side of the table, they are very evidence based. So you provide the evidence, and then the main part of the assessment is to check evidence for control design and control effectiveness. So SOC two works a little different than ISO certification audits. And then over time, these platforms have added support for other frameworks, for example, ISO management system standards.

But, like, the underlying structure and infrastructure of the platform was designed for SOC two assessments. And that's, I feel like, how this whole shift and this narrative entered the ISO world with, hey, it's just evidence, and you upload evidence and you upload screenshots, and then the auditor will look at that and you're good to go, which is not really matching what the actual expectation towards ISO management system auditors actually are. Yeah. Well, I fully agree with you here, and and I really don't like this approach of only, I don't know, written evidence is going to be enough because after all, also when I worked as an auditor, I also preferred to interview people and basically follow the lead, to say, and and really find out how to apply there.

Couldn't agree more. Okay. Now very often, auditees, so companies that are getting audited and people in there are kind of afraid that the auditor is going to interpret the standard in a different way. So let's say that that that or or in other words, they're not sure if what they're doing is really going to be enough.

What's your comment on this? It really possible that different auditors will interpret the standard in a different way? Well, I guess it's possible, but maybe taking a step back, I don't think it's my job to interpret the standard. My job is to assess the conformity of what the organization is doing with the requirements of the standard.

I mean, I know you are very well known for your expertise in the ISO management system world. I think we can both agree on the fact that every word, every tongue flick in these standards has a certain meaning. And every word has an official definition of what is meant with it. And there's dozens of guidance standards that really dive deep into what is the thought process, the underlying concept behind what is written in these standards.

So I think it's not my job to interpret the standard, but it's my job to assess the conformity with the requirements and to require not more than what is required, but also not to allow to go underneath the requirements of the standard. And I think what we all have in mind is auditors that pretty much declare best practices or their personal preferences as non conformities, which is quite common. I I just had an internal audit yesterday and there were some findings from the last external audit.

I mean, they're all pretty good guidance and good hints, but they were all declared as mandatory since they were nonconformities, but they were not backed by any requirement within the standard. By the way, I had a call the other day with one of our clients and basically the company had the audit, I mean the stage one audit, and there was a nonconformity raised by the certification auditor that they did not document clause 4.1, which is about internal and external issues. Right?

And I know that we already discussed this before, and I know our opinion, and I'm trying to explain to this lady that this is really not mandatory. If this is a small company and it really was a small company, doesn't make sense really to write down all the internal and external issues. Kind of doesn't make sense. So what can actually a company do in this kind of a situation if the auditor is pushing something that is really not required?

I mean, first of all, when you are in a closing meeting and it's about the presentation of the nonconformities, you are free to challenge. I mean, ask them, okay, we accept your opinion, but can you show us the requirement or which clause we would violate here? And this puts them in a position where they maybe have to open up the standard and to tell them, Hey, look here, this is the requirement that I'm referring to, and therefore this must be a nonconformity. Or they say, Hey, according to your own organizational rules, you are required to do so, but you're not doing that.

So I think this is the two ways that are existent. And I mean, that's I think the first approach to enter a discussion. And if you feel like, hey, we are not getting on common ground here, you can reject the nonconformity and get in touch with the certification body to resolve this matter. Right?

That's all. I think that's the best approach, trying to solve it with the auditor first. If you feel like, hey, we're on the right track, we can't, we don't agree with that, the next step of the escalation would be to reach out to the certification body. Yeah.

But I assume, you know, if if if an auditee presents this fact in a clear way that in most cases the auditor will consent afterwards and and really acknowledge that this is really not a nonconformity. So I assume that in large majority of situations, auditors are sensible and reasonable people that will admit if they were wrong with something. Yeah. Absolutely.

You know, what I tend to do in an audit, like when I have a nonconformity, I immediately communicate it within the audit session. And after every session, I always make a quick summary, thank them for their participation. And then, well, in this hour, I had one opportunity for improvement, I tell them. And then in the closing meeting I present it again.

So I just make sure that I'm transparent about what I have and to give them the chance to give feedback or to respond to if they have a different opinion. Yeah, it's much better actually to kind of resolve these issues before a closing meeting, right? You can actually see the feedback right away. Maybe it's also something to discuss with a cold beer after the audit day in the evening with the participants.

Give them time to process, give them time to think. It's always easier if there is some space in between, some time in between than if you just present them together with top management, then this is the final result. That's a bad way of doing. When you take a look at the main part of the standard, so clauses four to 10, the requirements are pretty clear.

They're very, I would say, clearly defined. But however, for controls, I mean, requirements are very generic, like for, I don't know, let's take the example of this backup control, my favorite. I mean, it doesn't really tell you what kind of backup you have to do, how often you have to do it, how often you need to test the backup. There is nothing.

So how do we actually conclude if a company really complies with the standard? So let's say hypothetically that they are doing backup only once a week. This might seem like not enough, but what do you do in an audit if you see a situation like this? I mean, first of all, I guess the whole approach of the standard is risk based.

So before you get to auditing the controls, you must have an understanding of their risk exposure and the risks they have and also the risks that they seek to, let's say, treat with their controls. When you get to the backups, I think the first question I would always ask myself is, does the company have maybe some sort of business impact analysis? If they have a business impact analysis, then it might be the case that they have to find a recovery point objective. If they have a recovery point objective, you can conclude that a certain system must also meet the recovery point objective.

Let's say you have a system that is backed up once a week, but the system belongs to a process that has a recovery point objective of twenty four hours. And if you can trace that back, you sort of find an inconsistency. So you can ask them questions: Well, here RPO is twenty four hours, The backup frequency in your backup console is one week. How does that fit together?

And then see what they tell you, right? And if it doesn't match, maybe you have found an inconsistency and you can raise potentially a nonconformity, but an opportunity for improvement for sure. Yeah, yeah. That's a very good example actually, that is kind of based on a detailed analysis.

But on the other hand, not many companies do have a business impact analysis, right? It's not mandatory. RPOs are not mandatory according to ISO 27,001. So how do you actually react in a situation where, you know, they do not have RPOs or BIAs?

I mean, if the backup, I mean, if you look inside of a backup console and you see that the backup frequency is set to one week, the backup console for me is an operational system. So you have an IT administrator that configures the system. But is the one week determined just by the IT administrator? Or is there an organizational rule that somehow states what the backup frequency must be like?

If there is no rule from the organization, it's just based on the decision of the IT administrator, I would argue this is not in the sense of a management system. A clear rule is lacking. So they would have to come up with that. If they have a rule and it matches the one week frequency that they have defined, I mean, the first place, it's okay, right?

It matches that. And secondly, I think what is also something that we shall not forget, in the end, are certifying a management system. Right? We are not certifying the security posture, if you will.

So if you have a high risk appetite, if you have limited resources, there might be a good reason why you have not the best and most up to date measures in place. So in the end, that's maybe kind of tricky sometimes to navigate, but we shouldn't forget we certify a management system and not the security measures in the end. Isn't it a little bit strange actually that when doing the audit, you're actually not certifying the security posture, as you were saying. You're basically certifying that they manage their security in a systematic way.

Isn't it a little bit strange or maybe even absurd, so to say, from a security point of view? Well, I think it's a very controversial topic. I mean, sometimes I work with clients and when you talk about their suppliers and contractors, and the only thing they request them to provide is an ISO 27,001 certificate. But in the end, you don't really know what's going on inside of that company.

Like, we are technically, you're on they only have a management system. So 2,000,000,000 corporation has the same ISIS certificate hanging on the wall than the five person startup from around the corner. And you can be certain that there is a big gap between what both companies are capable of doing in terms of security. Nevertheless, they get the same certificate.

So I think that's also a problem in terms of do people really understand what the certificate means? And I think there is a big misunderstanding for many, which I don't blame them, it's a complicated topic, but an ISO standard is a nicer standard, right? And that's just the way it is. No, I mean, you're right and I agree with you.

And basically, what I think is that if there is a good security management system in place, then the chances of actually all the security controls, so the technical execution will be I mean, the chances are the tech technical execution will be much better. Whereas if you don't have any kind of management system, you can be sure that technical execution will also be, you know, very, very bad. So I think that the the management system is a kind of, let's say, ground foundations, and then you're building on top of this everything else.

So from that perspective, it does make sense. Unfortunately, not many people understand it. They see only the technical part, they don't see why this management part is needed. What's also important to note is maybe every management system has a requirement towards continual improvement.

So for companies that, let's say, are a little bit longer in a certification journey that maybe have undergone one, two, three, four, five recertification audits, so that have been certified for quite a while. I mean, as an auditor, when you get back to these companies, you can always expect a little bit more because they have to continually improve the system. And that can also be a push that you can use as an auditor to get them to automate a process or to get them to purchase a system, right?

So there is some pressure to evolve over time, at least. Yeah, yeah. And I think that's very important. And especially when, I don't know, when people do the risk assessment for the first time, I tell them, look, you can't really assess all the risks.

It's impossible. No. But throughout time, because of this continual improvement, you'll add new risks and you will become more and more aware and you will improve your system because of that. Yeah.

So Absolutely. Absolutely. Yeah. Okay.

What is basically the difference between nonconformities and opportunities for improvement? So what when are you actually raising nonconformity and when are you just giving, let's say, some kind of suggestion or opportunity for improvement? Well, a nonconformity is a non fulfillment of a requirement of the standard or a non fulfillment of a requirement that comes from the organization themselves. So it is a clear, let's say, violation of a hard requirement.

An opportunity for improvement is something that is meeting the requirements or satisfying the requirements of the standard, but could be done in a more extensive way, in a better way, in an easier or more convenient way that could lead to an improvement, but still wouldn't violate a requirement. So if you encounter a nonconformity, it must be fixed. If you suggest an opportunity for improvement, the client is free to accept or decline this opportunity. Can you give just one example of how an opportunity for improvement could look like?

Just for everyone to understand what this could look like. I mean think about, if you look at maybe the password complexity rules of an organization. So you check for the complexity rules of an organization and they have determined complexity rules. So you feel like, well, the requirements for authentication information are there, they have a process for how to submit initial authentication information to an employee, and the password complexity rules are enforced.

But you realize the password minimum length is eight characters. And you feel like, well, practice, 12 characters at least would be better. So in this case, you wouldn't raise a nonconformity because the standard has no requirements towards password complexity. But from your experience as an auditor and as a practitioner, you tell them, well, given the current risk exposure that you have and the overall involvement of the industry, to raise it or to increase it to 12 characters.

That would be an offie, if you will. And this is, I would say, a very, very good example. Actually, is from what I understood, this is how you add value to the audit. Right?

So this is basically how you help companies improve their security since you already have experience. And you've seen lots of other companies how they do stuff. Exactly. And it's also one way of, I mean, as an auditor you're not allowed to consult, but by raising opportunities for improvement, of course, without actually detailing how to implement those, you kind of provide additional help and additional value to the audit without violating your independence as an auditor.

Actually, that's a very good point and a question here. So where is this line between auditing and consulting? So how far can you go with these suggestions as an auditor without doing the consulting work? I mean, that's of course dangerous territory.

You know, of course, in every audit, you will be on the brink of consulting at some point, especially if you encounter an auditee that is not really familiar with what you want to see, how this works. So you are sometimes tempted to tell them, well, simply click here or simply, you know, why don't you connect this with that and then then it's solved. So you are sometimes tempted to do that, but you should avoid it at all cost. Right?

Because in the end, if you suggest something, it will come back to you. If it's not perfect, in the end it's mistake and you can't audit that anymore. So that's tricky, but you have to be really careful with that. Okay.

Can we say that, I don't know, if you spend a couple of minutes explaining what the right way should be, it's still kind of not consulting. Whereas if you go, let's say thirty minutes or so, that would become consulting. Could this be a way to of I draw the mean, you know, if you explain a passage of the standard, like what is the overall intention behind that and what could it look like or how do others handle that, I think it's fine unless you get to a point where you tell them, do it like this.

That's not what you're supposed to do. Explaining the standard, I think that's fine. But, of course, you have to be we have to be very careful. And and I mean, kind of giving an overall, let's say, explanation of the standard and potential directions, not only one, but at least a couple of directions.

It's fine. And again, I think it gives additional value to the audit. And I think, you know, the companies will certainly prefer this kind of an auditor rather than someone who doesn't say anything. Right?

Absolutely. So I think this is very, very important. Okay. Now, many companies actually think that the role of the auditor is to find non conformities.

Is this true or is actually the auditor about something else? I think the overall job is to assess the conformity with the standard. So I'm not tasked to find non conformities, but I'm tasked to assess the conformity. And I I think it's a mindset, you know.

I don't enter the audit with the mindset of I have to find something today. Like, that's not how I approach it. It might be different for others. I don't know.

I heard some heard some weird stories about some others. But, anyways, you know, I think for me as an auditor, I don't want to, you know, create additional friction. I don't want to, you know, cause harm to any business. In the end, I try to get there and to help them in their certification journey, raise potential opportunities for improvement.

And if there are nonconformities, then I think it's something positive to tell them: Hey, there is something that you can do better, there is something that's not right at the moment. So feel myself, when I'm in an audit, I want to be an enabler to them. And most companies and clients I have are very open and very positive to that. There are some cases where as an auditor you're kind of considered as the enemy, which is kind of weird because I'm not that in an audit.

But most of the time I feel like I try to contribute through my auditing to the overall success of the company. It's a very good point. And I mean, it would be better if most companies actually would understand this kind of an attitude from the auditor. As you were saying that the auditor is here to assess the level of conformity.

He's he's not here to primarily find the nonconformity. So, So if this kind of positive relationship or if an auditee would have this kind of positive relationship towards the auditor, the whole thing would be much smoother and everyone would have an easier job. Yeah, absolutely. And you can always tell in an audit if the auditee is transparent and openly communicating with you or in Germany we say if you have to pull everything out of their noses and everything is a battle and a discussion, that can be very tiring if you're auditing them for multiple days.

So I really prefer it to be the other way around. Just much more convenient and more beneficial in the long run. Absolutely. Yeah.

Yeah. Yeah. Okay. Let's wrap up the call.

So as a last question, what would be, let's say, your top suggestions on for companies? What are the most important things they have to prepare before they go for ISO 27,000 certification audit? Sure, sure. Well, I think as you mentioned before, a management system is more than just having a couple of policies in your folder.

So make sure to think about how to operationalize what you have in mind and check for: Is the organization actually doing what we have written in our policies and what our processes and procedures require us to do? And secondly, the audit can be very positive. So there are some auditors that have long term relationships with their clients that accompany them through the years and have helped them through taking the next step in the maturity ladder and while being outside of the organization.

They sort of become part of the team. I mean, still independent, but they're just part of the family and they really help to the success that everybody wants to achieve. Great. Okay, great.

Thank you for these insights, Aron. It's been a pleasure talking to you. Absolutely. Appreciate it.

And thank you so much for having me, Dejan. It was really a pleasure to be here. Great. Thanks again, Aron.

And thank you everyone for listening or watching this podcast and see you again in two weeks time in our new episode of Secure and Simple Podcast. 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.

For example, Conformio software enables you to streamline and scale ISO 27,001 implementation and maintenance for your clients. White label documentation toolkits for NIS2, 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. 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!