How to Integrate Security Controls Across ISO 27001, NIST & SOC 2 | 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, and I'm the CEO at Advisera and the host of Secure and Simple podcast. Today, my guest is, Aron Lange, and he's the founder of, the GRC Lab and works as a consultant trainer and also as a certification auditor for, TUV, Sud.
Dejan Kosutic:And as a consultant, he helps clients with various standards, including ISO 27,001, TISAX, which is a cybersecurity automotive standard, and C5, which is for cloud companies, but also for ISO 27,701. Also as a trainer, he developed courses for ISO 27,001 and for NIST Cybersecurity Framework. So in today's podcast, you'll learn how to combine security controls for various frameworks. So welcome to the show, Aron.
Aron Lange:Hi, Dejan. Thanks for having me again. Really excited to be here again.
Dejan Kosutic:Great to have you here. And just to mention that we had a great podcast a while ago about the certification auditors, certification audit and what the auditors will be looking for. So if our listeners are interested in that topic, just take a look at at this one episode that we had a couple of months ago.
Dejan Kosutic:Okay. So switching to to controls. So there are many security frameworks out there. So which actually set of controls do you prefer the most? So is it like ISO 27,001 or or NIST Cybersecurity Framework or NIST 853 or SOC 2 or some other?
Aron Lange:Well, that's a great question. And I think this takes us to the root of a lot of misunderstandings that are out there about controls. So I think that we have to distinguish between what are requirements and what are controls. Now there are frameworks that explicitly state we simply state criteria or requirements. For example, if you look in the NIST Cybersecurity Framework, then they clearly state in the beginning that this framework does not include any controls, but we merely describe a set of preferred outcomes that can be achieved or, let's say, can be satisfied through the implementation of appropriate controls.
Aron Lange:And for controls, you have to look inside of control catalogs. One of those control catalogs, and to answer your question, is NIST Special Publication eight hundred-fifty three, which is a very extensive set of controls. I think it's around 1,500 controls that you find in this catalog that covers everything from governance all the way to the nitty gritties of technical security, access control, encryption, all of those things. So this is my go to resource because it's very extensive, very well structured, and you pretty much find anything you can imagine without having to read between the lines, which is the case for other control catalogs.
Dejan Kosutic:Okay. And when you con call it, say, compare this s p 853 with, let's say, s p eight hundred one seventy one, which is, let's say, a set of controls for CMC. How would you compare them? I mean, I I know that one seventy one is actually has a lower number of controls. It's it's and it's focused mainly on this what is important for CMC.
Dejan Kosutic:So for this CUI, the the basically classified information. Right? Yeah. So what do you think about these two standards when you compare them?
Aron Lange:Well, I think what we have to understand is eight hundred-one 171 is used pretty as much as an imposed obligations or requirements that must be fulfilled by companies. And now the thing is, what governments typically do is, they do not tell you how to do things, but they tell you what to do. And now to frame that right, a comp a government or, let's say, any governing body will not tell you how to do things, meaning they won't prescribe controls. So what they state is, hey, we say these are requirements that companies must fulfill. But how you fulfill them is up to you.
Aron Lange:And this is like aligned with the approach that NIST has. So a requirement is satisfied through the implementation of a control. And by not phrasing it as controls, they circumvent the fact that they do not want to prescribe the companies that fall under CMMC what they have to do in specific.
Dejan Kosutic:So what you're saying is that 171s are mandatory controls because of CMMC whereas NIST 53 basically provides a catalog where companies can choose which controls are applicable, right?
Aron Lange:I would phrase it in a different way. When we think about a con let's say, I think documents of authority, for example, 171 or let's say the GDPR or the NIST two Act in Europe, These documents, they describe requirements. Requirements that must be fulfilled. And how do you fulfill those requirements? You do so by implementing controls.
Aron Lange:For example, a requirement can be: Access to information shall be restricted to authorized individuals. Now the question is: How do we get there? We get there by implementing controls. And the controls are the policies, our procedures, our ACLs, our systems that actually restrict access to authorized individuals and thus satisfying the requirements that are stated in the documents of authority. And I know it's kind of like let me say, like, picking in German, But it's not really the same.
Aron Lange:So a control is not a requirement. It's really hard to grasp, but I think that's a very important distinction. And it's underlined because in 1.71 they also talk about: Hey, these are requirements without calling them controls, basically.
Dejan Kosutic:Okay. And just for comparison, you you mentioned that you also work with the C5 and with the TISAX. So how are the requirements? Let's say, how detailed are the controls or requirements in those standards?
Aron Lange:Well, in case of C5, probably have to say a few things about C5. It's like a cloud computing compliance criteria catalog. So it lists over 600 criteria that must be fulfilled when it comes to securing cloud services. It's the German standard. And here again, they also explicitly state that we have criteria, and you are supposed to fulfill those criteria by implementing controls that are then assessed by a certified public accountant.
Aron Lange:So it's kind of similar to SOC 2. And where they get of course, they get very specific. It's like 600 requirements, over two fifty pages as far as I remember, where you have a lot of detailed descriptions of what must be done without specifying the how, for example.
Dejan Kosutic:Okay, good. And TISAX is also as detailed or not so detailed?
Aron Lange:It's not as extensive as C5. I think TISAX is pretty much an ISO 27,001 with specifics for the automotive industry. So you I mean, you you also live in Europe like I do. So probably you have seen a few cars on the road that have, like, this camouflage on top of them, the black and white stripes.
Dejan Kosutic:Yes.
Aron Lange:And this is a TISAX requirement, quite frankly. It's the protection of prototype or test vehicles. So Mhmm. In order to get an approval for a car to be sold to the public, it has to undergo, like, a test period on the street. And because they don't wanna disclose the the final design or something like that, they put the camouflage on top of that.
Aron Lange:That's, for example, some TISAX, which is not ISO 27,000 unrelevant. It's like it's just for a very small portion of companies. But in TISAX, you find those requirements, for example.
Dejan Kosutic:Okay. So you mentioned earlier that you kind of prefer this NIST SP 800 dash 53, which is pretty detailed because it provides lots of useful information. But okay. For someone who is really experienced like you, it's it's probably the best resource.
Dejan Kosutic:But let's say someone who is really starting out and and doesn't have much experience with all of these controls, Do you also think this should be the, let's say, starting point or maybe they should start with some less detailed or less complicated framework?
Aron Lange:I mean, question is always what you're trying to achieve, of course, and also how much prior knowledge you have. Many companies, they start with ISO 27,002, which is also a great resource. But the problem with ISO 27,002 is you only have 93 controls, at least that's what they call it. And then under each control, you have an implementation guidance that often spans one or two pages, and then you can find useful guidance all throughout the document. So Yep.
Aron Lange:I think if you, like, really dissect it, it would be a lot more controls actually than just 93. But you really have to find or search in between the lines for all the useful guidance. Whereas in the list catalog, a control is always one statement, and then you have a guidance, and then another control, and another statement. And it's like very more granular and easier to navigate and also easier to search, quite frankly. So I think this is an advantage, but it can also be intimidating at first.
Aron Lange:Obviously, 1,500 controls, that's nobody nobody can do that right away. It's not possible.
Dejan Kosutic:Okay. Now do you do you actually recommend your clients or or, let's say, your your students to map controls between standards, especially if they want to implement more than one standard?
Aron Lange:I mean, that's the that's the great struggle of our time. I mean, as soon as you have to comply with multiple frameworks for whatever reason, I think you are kind of forced to do some sort of cross mapping and figure out, hey, how much did do we already cover of that new framework and what's left, what's missing, what what how far is the the road still ahead for us. And I wouldn't recommend it to I wouldn't recommend them to do their own cross mapping, but to search for validated, well researched mappings that are already out there.
Dejan Kosutic:Okay. So are there some, let's say, more popular ones? Like, is there some kind of, I don't know, repository of of these things or or this is something that is more not very not very open shared?
Aron Lange:I mean, there's everything. There's very scientific approaches. I mean, don't wanna mention any vendor names here, but there's some organizations that focus on creating these focusing on creating these meta frameworks. There's also other resources. And I think from overly scientific to absolute voodoo magic, you find everything out there.
Dejan Kosutic:Yeah. But what would be your criteria to choose? Which one would you prefer? Methodologically, which do you find the best?
Aron Lange:Methodologically, I find the best that follow the more scientific approaches. So there is there is an approach also by NIST that describe how a cross mapping works between control frameworks. There's also a special publication about that topic. I I forgotten the number, but, basically, you know, back in back in the days in school when we were taught when we were, studying mathematics, you know, when you have, like, two amounts of, let's say, numbers, then, you know, they can either intersect or completely converge or being completely separated. And that's pretty much an approach that tries to compare two sentences and then to figure out are they completely overlapping, are they completely divergent, or is there an overlap?
Aron Lange:And then you have, like, an indicator of of overlap, and then you can work with that. But, it's kind of voodoo. And I think with the recent AI and LLM wave, stuff sort of starts to lose its its relevance with the new technology.
Dejan Kosutic:Yeah. You're right. Obviously, I mean, if if you can actually ask AI really to to do this as well and then double check if if this is correct. Yeah. Good. Now since you know I mean, since you work with several frameworks, did you notice that maybe controls from some of these frameworks are contradictory, one to each other?
Aron Lange:I mean, I haven't really had a case where it's, like, impossible to come to comply with two frameworks at the same time. I I haven't had that. I mean, obviously, they're quite often complementary. So when we think about NIST two reporting obligations for incident management, I mean, that's something that NASA twenty seven thousand and one does not prescribe. So, I mean, you can come up with whatever you feel like is appropriate.
Aron Lange:But as soon as you bring in this two into the equation, it becomes a clear, Hey, early warning, status update and final report within seventy two hours. So that's where they complement each other. Contradict, to be honest, can't think of an example right now.
Dejan Kosutic:Yeah, I didn't find either. So I'm just kind of double checking if there might be something. But I didn't really see anything.
Aron Lange:I was afraid I missed something.
Dejan Kosutic:No. I don't think so. Okay. So let's kind of move the topic to, let's say, more kind of implementation issues. So do you do you think that a company can run, let's say, one security system, whatever it's called, I don't know, SMS or something else that actually covers several standards?
Dejan Kosutic:So is it possible actually to integrate everything into one system and then run it as such?
Aron Lange:Absolutely. I think when we look at the inherent principles that are laid out in ISO 27,001, the risk based approach, risk assessment, risk treatment, evaluating performance and just continuously improving, then those inherent principles are pretty much found, I think, in any framework I can imagine. I mean, the cybersecurity framework with its six functions, from detecting and identifying vulnerabilities and risks all the way to responding and recovering to incidents. Same in TISAX, same in c five.
Aron Lange:It's always pretty much the same story. So I think if you can manage to really integrate them well, it's it's really it's it's perfect. But the problem is always, what are the specifics? Where is the overlap? What's still missing?
Aron Lange:And still to this day, there's not really a a great solution out there that has really solved this. Many are on the way to get there, but it hasn't been done before.
Dejan Kosutic:Okay. But, I mean, these overlaps, do you actually resolve them by this, let's say, mapping that we discussed earlier, or is there some other method actually to to resolve these overlaps?
Aron Lange:I mean, I'm very fortunate. The clients that I work with, I typically have them add one framework at a time. So let's say they have started with ISO 27,001 and then they decide, hey, I would like to add T cells. And then what we typically do is, we go through the new framework section by section, and we make a gap analysis or cross reference to what we already have. And then we just move forward step by step, and we check if what we already have meets the new requirements.
Aron Lange:And if not, we make an action plan and initiate the necessary changes, and then we go on from there. This does, of course, not work if you have a company that approaches you and asks you, hey. I want to add ISO, T sucks, and c five all at the same time. That's tricky. That's much more.
Dejan Kosutic:That's always the biggest problem. Yeah.
Aron Lange:Yeah.
Dejan Kosutic:Okay. How do you then explain to a client that it's not a good idea to go with all three at once? I mean
Aron Lange:Well, I mean, a client is king, obviously. I mean, typically, when you when you talk to the people that are in charge, they sooner or later realize that this is like an impossible task to approach everything at once. And at least in my case, I was able to convince them of phasing it out and going step by step.
Dejan Kosutic:Easier, much less stress. Yeah.
Aron Lange:But yeah.
Dejan Kosutic:Okay. So earlier I mentioned that basically the standard my the standards are, let's say, different when you read them, but, ultimately, the same logic applies in all of them. Right? So it's it's basically the same. Now where I found that the what what I found actually is different is that some standards are specifically that the the focus or I s m sorry.
Dejan Kosutic:The scope of some of these is different. For example, CMMC is obviously focused on this controlled unclassified information CUI. Right? Whereas PCI DSS is specifically focused on on payment systems. Yeah.
Dejan Kosutic:So if you actually have, let's say, standards that are such specific that has such specific focus or scope with some more generic standards like ISO 27,001, how do you actually then combine all of these things together so that even though the scope is different, you actually have one system? So any comments on this?
Aron Lange:I mean, like I mentioned, the trick is to find the overlapping parts of the standard. So for example, identity access management. This is clearly a topic that you will probably find in most frameworks. And typically it's also easy to distinguish because there's a section that either says Access Control, Identity Management, IAM or something like that. And then the trick is to put them next to each other, give a visual example, and compare.
Aron Lange:Cross compare and check what must be done. I mentioned the reporting obligations, for example, from this too in case of a severe security incident. This is obviously something that might be different within this too than it is, for example, in GDPR. And now your job is to find out when does which apply and how does it fit or how does it align with our reporting process. That's kind of how you glue it together.
Aron Lange:Then you have a final result. And then hopefully we'll do a final cross check and see if all the requirements that affect this process are met by what you have established. Mhmm.
Dejan Kosutic:Yeah. Makes sense. Definitely.
Dejan Kosutic:Okay. Now if a client wants to implement several frameworks, like okay. Either at the same time, which is obviously not preferred solution or one after another. Mhmm. Yeah.
Dejan Kosutic:Would you actually, let's say, suggest what should be the leading standard or would you always suggest, let's say, one standard to be kind of the the core and then build everything around that one standard. So what is your approach usually?
Aron Lange:From generic to specific. So I would always begin with establishing the basic management system. So for example ISO 27,001. And then I would add the more specific frameworks. And I think that's also greatly aligned with how the standard is supposed to work.
Aron Lange:I mean, I don't have to tell you, but that's the context of the organization, the requirements of interested parties that you are supposed to identify. And, And if you process credit card information, then of course you are subject to PCI DSS. And it's the job of your management system to identify those requirements and to take them into consideration when conducting your risk assessment and also when implementing your controls. It's the engine and everything else is attached to it. And then you can only succeed if you do it right.
Dejan Kosutic:Okay. So if I understood what you're saying is that, let's say, a more generic standard is something like 27,001, which can then be the basis for for some others. Okay. Yep. Okay.
Dejan Kosutic:I agree. I mean, I also I'm very much biased towards the twenty seven thousand and one, but, yeah, I I really think it's flexible enough so to say that you can absorb also other requirements from other standards. Yeah.
Aron Lange:Yeah. Okay.
Dejan Kosutic:Got it. Sure. Now if let's say let's compare, let's say, the situation where you implement only one standard with the situation where you have to implement a couple of standards together. Now what are, let's say, the differences in approach in the implementation approach or in the steps when you implement only one standard versus several of them? So what is basically different in the implementation?
Aron Lange:I mean, when you only implement one standard, you pretty much only have one authoritative source that tells you what must be done. Right? Mhmm. So you have one catalog, and you can pretty much just go through the catalog and see what's inside and then make a plan in order to get there. As soon as you have multiple frameworks like we mentioned before, you might have two sets of requirements for the same process, for the same topic, for the same domain.
Aron Lange:And as you mentioned, is there something contradicting? Is there maybe the same requirements stated twice with just a different use of words? You know, you can say the same thing but using completely different words and it has the exact same meaning. That can be a challenge, of course. And maybe is there something complementing or something additional, something sharpening, right?
Aron Lange:Where it's stricter, more precise, like a password length? No, I mean ISO doesn't prescribe a password length or capacitor complexity rules. When we talk about C5, it's maybe a little bit different. Maybe there is something for password complexity. And then you have to glue it together.
Dejan Kosutic:Yeah. Okay. So what you're saying then extra step or steps are actually comparing requirements of various frameworks. Right?
Aron Lange:Yeah.
Dejan Kosutic:Is there anything else? Is this the only thing that you really have to do when integrating standards?
Aron Lange:The big question is what you are trying to achieve compliance with. So in case of ISO 27,001, it's clearly a management system. When you think about SOC 2, for example, it's a service that is in scope. Same for C5, it's a cloud service. Uh-huh.
Aron Lange:So in those cases, you have to provide like a system description. Now the question is, is your management system also covering the cloud service or the the system that you would like to have then observed by by a CPA or not? Does it have to overlap? Is it necessary? Maybe maybe not necessary.
Aron Lange:Right? So these are also considerations that you that you have to be aware of. Then many frameworks are also allowed to be scoped. So when you think about TSX, for example, for the automotive sector, I mentioned their requirements for camouflaging cars. I mean, if you are an IT service provider, you do not have access to prototype parts, you do not have test vehicles on your premises, you do some IT services.
Aron Lange:Those requirements do not apply to you. You can cross them out in the beginning, but that's that's a scoping issue. So that's maybe What also something that must be brought into is the scope of this? What is the objective? And also what is the assessment in the end going to look like?
Dejan Kosutic:Yeah, so obviously the scoping is another, let's say, thing to consider even actually before considering the controls. Yeah. Definitely.
Aron Lange:Yeah. Yeah.
Dejan Kosutic:Okay. Do you perhaps have an example working with companies? I mean, without naming any of these companies, do we have an example where actually additional standards has helped a particular company or when additional standards has really made a mess or or really a big problem for for the company? So are there some examples of, let's say, positive and negative implementations?
Aron Lange:I mean, I've had recently a case of a very positive case. It was like a small startup in Munich, in the health sector, the healthcare sector. And according to German laws, you provide a cloud service to doctors, hospitals and so on, your company has to present a valid C5 attestation, like a German SOC two, if you will. And this company started up 15 people, they had really nothing in the very beginning, a great product but no management system or something like that, a startup. And they wanted to start with C5.
Aron Lange:And I urged them, Hey, start with ISO 27,001, make the basics, and then afterwards we're going to add C5. And within four months they were ISO 27,001 certified, and within another four months they managed to get the C5 attestation. Although they wanted to do it all at once, in the end it was the right choice to do it step by step. There was enough time, there was no issues, and the organization had time to mature and to adapt and to now get accustomed to the new way of working, a startup, not add processes, you know, what it's like. So that was a very positive case.
Dejan Kosutic:Are you saying that it's actually easier to implement C5 if you already have 27,001 as a base?
Aron Lange:Absolutely. And the striking part is also, if you open up the C5 catalog, which I'm sure you will after this session, the very, very first requirement of C5 is to have an ISMS in accordance with ISO 27,001.
Dejan Kosutic:Fine. So did you ever, let's say, consider what kind of KPIs could be used to to, let's say, measure the success of of this integration between two standards?
Aron Lange:The success?
Dejan Kosutic:I mean, I didn't come up with anything, you know, very, very smart. So maybe you have something.
Aron Lange:I mean, the question is always, do you need to prove compliance with additional frameworks? I mean, you also have a company and you could decide for, hey, let's certify Advisera against this or that standard. And then you could say, hey, we could add another standard and another standard and another one. And, of course, the certification party, they would rub their hands and, of course, we can make money with business with you. Yes.
Aron Lange:We're certify you. But the question is, what is the benefit of adding other standards? In case of C5, if you are a cloud service provider and you feel like, hey, we want to improve, but no client is asking C5 from us and there is no law in our country that urges us to be C5 compliant. But we can still open up the framework and look for guidance and implement some of those if it helps us, without getting into the regulatory overhead and the pressure of undergoing the actual audits. So I think it's not always necessary to be so strict, just to be open minded and to just use the best parts of it.
Dejan Kosutic:And I mean the measure, the benefits of additional standard versus let's say additional effort or whatever, I don't know, stress there is for a company for implementing another framework. Basically, these kind of things theoretically could be measured if someone wants to try to do it.
Aron Lange:I mean, case of T cells, for example, it's often a requirement to have it you want to make business in the automotive industry. So Mhmm. You could say, hey, how many deals did we win or could we close because of the TSX labels that we have obtained. Right? Yep.
Aron Lange:That's something, of course, for the managing directors. That's great information. But I think that's pretty much all I can think of in that respect.
Dejan Kosutic:Okay, let's re topic a little bit towards statement of applicability. So this statement of applicability as a document is mandatory for ISO 27,001 is and is obviously very important for certification auditors, but also for companies themselves. Yeah. Now is this is there such a requirement for such a document also? Does it exist in, let's say, NIST or TSX or C5?
Aron Lange:Yeah. In TISAX, there's actually a requirement for the organization to have a statement of applicability or to use the TISAX catalog, a filled out TISAX catalog instead. C5, I mean, you have to have an ISMS in accordance with 27,001. So again, you have to have a statement of applicability. And I think for SOX2, since the controls are assessed whether the SOC requirements are met or the the requirements that are, like, underneath it, you also have to have some sort of, like, control description, control design.
Aron Lange:So similar, but it's not called statement of applicability.
Dejan Kosutic:Now the question is if you have to create this statement of applicability basically after you do the risk assessment, right? So you basically assess the risks and then find out which controls would be applicable. So what is your, let's say, preference or what is your I don't know. Do you think that the companies should basically use catalogs from these standards, catalogs of controls, then based on those create a statement of applicability or simply list the controls they identified during the risk assessment and treatment process?
Aron Lange:Yeah. I think it's beneficial for our audience to take a small step back. I think we always talk about SOAS and Sapiens of Applicability, but the question that comes to my mind is: I mean, why do we have to have this document? And that's a huge topic in my opinion. So when we think about ISO 27,001, every company that gets certified gets the same certificate in the end.
Aron Lange:It doesn't matter if you are a five person company or a 15,000 company. You will get a certificate with an accredited logo twenty seven thousand and one and a date and an expiration date and that's it. Obviously, you can compare those already. I mean, you know they comply with the requirements of the management system. But what are they actually doing to protect their information from CIA, right?
Aron Lange:And that's actually where the statement of applicability comes in, which, by the way, must also be referenced on the certificate. And technically, if you have, let's say, a supplier and you request their certificate, you can also request them to provide them with their SUA. So you can have a look at what are they actually doing. Now what you see in reality is: 99% out of all organizations, they simply go ahead and they take Annex A, copy, and they go into their ZOA and they paste. Now you have, I don't know, 50,000 certified companies in the world that are all ISO 27,001 certified, and their SOA almost looks identical.
Aron Lange:What's the structure you know about these companies? It's completely identical, and you have no in Germany, say, you have like no clue what they're actually doing, which completely defeats the purpose of the document. And that's also the sad part. And now getting back to your question, you already phrased it right. The standard requires us to list the necessary controls.
Aron Lange:That's what we are supposed to do. I mean, here's my key fob. And I have a YubiKey on it, a hardware security key. And that's sometimes my primary factor for authentication, sometimes my secondary factor for authentication. So that's a measure that I control that my company has implemented.
Aron Lange:And that's actually something I would like to see on a statement of applicability. But instead, companies would simply go ahead and copy paste control eight dot five from Annex A, which is called Secure Authentication. And then when you read that control, it's some gibberish with technologies that are in accordance of your access control policy or something like that, which gives you no clue if they have MFA or if they have SMS or if they have something sophisticated like hyper security keys. But you have no clue what they're doing. And that's the state of the art when it comes to servers in the world.
Dejan Kosutic:Okay. So what you're saying is that companies should not at least not in the in the first time, they should not care about the list of controls in the in the standards. Rather, they should list the controls they consider are necessary. And then what? Check against the standards in the later step or
Aron Lange:I mean, now it comes to to like like actual control catalogs. So, for example, I mentioned hardware security keys. When you look in into NIST special publication 853, MFA hardware security keys, that's a thing that you find in there. If you look inside of Annex A, it's not listed. I mean, if you look inside of twenty seven thousand two, then in the guidance, you will find a few sentences about MFA and hardware security keys under 8.5 or some other controls. But if you just copy paste secure authentication into your SOA, technically, at least of my understanding, you have not listed the necessary controls.
Dejan Kosutic:So what you are saying is that companies can, if they only copy and paste the name of the control, they actually might miss what is important, really important from that control or related to this control, if I understood well.
Aron Lange:Absolutely, the thing is when it comes to secure authentication, there is a variety of ways to do it. Everybody knows about second factors, authenticator apps, SMS, hardware security keys. Maybe sometimes it is even not possible to have a second factor, Biometrics, you know, dual authentication, like in the Hollywood movies when they turn the key at the same time to people, you know. Like, all those things are possible, and those are the actual controls that you implement. Another SOA actually is the document that lists those, that provides some insights, and it also is very important for me as a certification auditor, because my job is, if we look into 27,006, the standard that describes conformity assessments, it's very clear that I have to check the controls from the statement of applicability, not necessarily the controls from Annex A when I audit the management system.
Aron Lange:But if the Annex A is just a copy paste from Annex A, it kind of gets tricky of what they're actually doing. I mean, we know how it's done, how audits work, but I think it's not really how it's supposed to be.
Dejan Kosutic:Yeah. Okay. I I mean, I do see your logic. However, you know, companies in in this case, if they actually start listing all the controls, they might end up with the statement of applicability with, I don't know, a thousand items. Right?
Dejan Kosutic:So isn't it, let's say, easier to, let's say, group those controls into controls according to, let's say, 27,001 or or some other standard? And then say, look, for, I don't know, Control eight dot five secondure authentication, we have the secure authentication policy. And then as part of this policy, then you cover, I don't know, YubiKeys, I don't know, two factor authentication, passwords, whatever.
Aron Lange:I mean, I mean, we are both auditors. I mean, the the the standard is does not prescribe the how. Yeah. Clause six point one point three, I think it says list the necessary controls and then compare them with the ones, the reference controls listed in Annex A. That's pretty much all you get.
Aron Lange:I mean, I think there's, of course, multiple ways for what a statement of applicability could look like. And we are probably not getting to a definite solution here. But also think about this: many companies have multiple sites. They have multiple sites, they have multiple IT systems. Let's think about physical security.
Aron Lange:On the headquarters, they have surveillance cameras. Now two weeks before the audit, they acquired another company with a physical site in Zagreb, for example.
Aron Lange:They are planning on rolling out the surveillance cameras at their new facility or their new site in Zagreb as well, but it's not there yet. What is in your statement of applicability?
Aron Lange:Yeah. Physical surveillance, is it a green check mark? Is it in progress? Or do you distinguish between the headquarters in Munich and the satellite office in Zagreb? That's also not done by many companies.
Aron Lange:They just have annex a copied, but it's more nuanced. And that's also an idea of the statement of applicability, the implementation status.
Dejan Kosutic:Okay.
Aron Lange:And to be honest, it can be different if you look at multiple IT systems or multiple sites. Right? So that's also a chance for the statement of applicability to provide information, not just for the auditor but also for clients and also for the organization themselves. But if it's just a new copy paste, you pretty much lose all the benefits of it.
Dejan Kosutic:Now going back to this discussion about various controls from various standards, so which approach I mean, if your company is or if a client's company is implementing several standards, then which kind of approach of how to create this statement of applicability is the most appropriate in this case of integrating standards?
Aron Lange:I mean, there's probably I mean, to be to be honest, to be really, really honest, I have never seen a statement of applicability that is not a copy paste of Annex A. So I can't really give you...
Dejan Kosutic:Me neither. No.
Aron Lange:Exactly. I can't really give you an opinion on on something. I I I mean, I have an opinion, but I've never seen it. Mhmm. If you use multiple control sets, you could, of course, just copy paste all those control sets.
Aron Lange:But then the question is, what is the overlap? So then you have controls, let's say, from from NIST about access control, then you have the ones from ISO, or maybe you add PCI DSS to the equation.
Aron Lange:And then you might have the same controls that did multiple times. So probably you would instead of like a meta meta framework or meta controls, right, that kind of the Rosetta Stone or the umbrella that structures it. But I have never seen that. It's it's
Dejan Kosutic:Yeah. Yeah. Yeah. I mean, it seems that companies are still going this easier way by simply listing all the controls from a particular framework and then simply defining which one is applicable, which one is not, then maybe adding some implementation methods. Mean, referring to some other document or maybe some technical methods to do it.
Dejan Kosutic:It's in the most cases. But I do see your point, especially if I'm in the position of a buyer of certain services from a supplier, I would like to see a more transparent document, as you were saying, where more concrete controls are listed, because then I can say, okay, really I have now a better feeling of what this supplier does.
Aron Lange:And that's where the benefits of SOC two and C5 come in because there you don't get a certificate, but you get a report, a detailed report where you see what was assessed and what was the result. So you have Mhmm. More meat to the bone, as we say. So you get like a 100 or a 200 page document. I mean, I if if you have like an AWS tenant, you can simply request their SOC two report.
Aron Lange:Just make an account and request their SOC two report, and you get a 300 page document that describes their services, and you get everything that was tested and the results. And that's something that you can work with. With an ISO certificate, with a nice shiny logo, and a copy paste of Annex A, pretty much you know nothing about the company.
Dejan Kosutic:Yeah. Okay. Good. Let's wrap up the discussion today. So what would you recommend as a tough things to to companies or consultants when integrating controls from from various standards?
Aron Lange:What would I recommend? I mean, I would recommend not to get lost in perfection. In the end, it doesn't have to be perfect. So you don't have to take every word into consideration and try to be super, super, super precise. Just get started, you know.
Aron Lange:Establish a policy or a process that somehow fits and then just iterate from there. You know, try to improve and then try to get closer to actually meeting the requirements step by step without trying to, you know, pull everything together and then have the perfect deliverable right away because that's not gonna work.
Dejan Kosutic:Great. So thanks for these insights, Aron.
Dejan Kosutic:So it's been a pleasure talking to you today.
Aron Lange:Absolutely. You're very welcome, Dejan.
Dejan Kosutic:Okay, great. So thanks again and thanks 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.
Dejan Kosutic: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 2, 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.
Dejan Kosutic: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!
Creators and Guests
