Building Trust with AI Compliance Frameworks

Welcome to the Risk and Advisory Podcast. I'm Lauren Ross, a senior manager in our cybersecurity practice here at Cherry Bekaert, and today I'm joined by Steve Ursillo, a partner in our cybersecurity practice, and Morgan Haag, a senior manager at Meditology Services, which is a top-ranked provider of information risk risk management, cybersecurity, privacy, and regulatory compliance consulting services for healthcare organizations. And today we're kicking off a 3-part series on AI compliance. And so to start, we want to jump right into AI compliance frameworks. Steven Morgan, thanks so much for joining me. Thanks, Lauren. Pleasure to be here. So starting with SOC 2, so while SOC 2 wasn't originally designed for AI-specific risks, It covers security, privacy, availability, confidentiality, and processing integrity, which are critical for AI governance. So Steve, how can SOC 2 reporting give confidence in AI systems, and what are some practical add-ons that strengthen overall assurance? Thanks, Lauren. And I think that's a, that's a pretty common question. So, I mean, ultimately, when you talk about SOC reporting, system organization control reporting, SOC reporting is really a, it's really a reporting framework for organizations to really provide the level of depth and transparency on their internal control processes really related to the criteria which you mentioned, right? So if a service organization has a particular SaaS or infrastructure as a service or platform as a service, whatever the offering might be, and they have service level commitments that they are really reaffirming to their customers, whether it's uptime, security, confidentiality elements, certain types of KPIs or reporting elements to hold them accountable for performance. These are all typically service level commitments. And what the SOC does, the SOC 2 in particular, is it helps organizations really be held accountable for not only the design but the operating effectiveness of the controls to help them ensure that they're meeting those service level commitments. So that said, you know, your typical SOC 2 is going to include a lot of the common control expectations and security, but it extends based on additional criteria. Now, as it stands right now, you know, SOC 2 is built on COSO. COSO is a system of reporting for internal control. If you're looking at AI and you're looking at the risks around AI and the governance expectations around AI, you can certainly start to unpack what's relevant there to provide a certain level of transparency, oversight, and accountability for the controls in order to meet service level commitments. Now, typically the criteria is predicated on what we call points of focus. And once again, those points of focus are designed to be broad enough and customizable enough that organizations could bring in, you know, third-party criteria, whatever it is. It could be ISO, it could be NIST, it could be, you know, just about anything you really could think of. It could be HIPAA privacy security implications, anything like that. So it does allow allow for a certain level of depth depending once again on those service level commitments. So when you think about AI in particular, right, while it may not be explicitly mentioned in there, we do want to make sure that the SOC 2, when it comes to service level commitments and the use of AI, is explicitly scoped in. So we want to make sure that it's operating securely, reliably, and accurately in line with those service level commitments. And in certain cases, obviously, if an organization is relying on AI as part of those certain service level commitments— so for example, let's say the AI system supports anomaly detection for like fraud monitoring or something like that, that could be core to the system level commitments as to why the user entity or the customer, you know, subscribed or is using that platform. Therefore, you know, there should be the appropriate risk management measures built into that, including the governance and the predicated controls in order to mitigate those risks. And we would expect to see that in management system description and of course in the design and operating effectiveness of the controls. This would provide the appropriate level of fairness, you know, accuracy commitments. It would be useful for organizations to be able to understand their model registry as far as what they have in the models, what types of logs and monitoring they're using to make sure that they're staying within the boundaries and expectations as part of that monitoring. And overall, it just, it's going to provide a good level of how AI is being used. What's the purpose? What's the model type? What are some of the assumptions? Well, how is it using data? How is it actually gathering evidence? Is it doing things as it pertains to testing for bias or any type of drift monitoring, anything like that? And also, if there's any human in the loop or any type of other types of human factors there as part of that process in order to help emphasize the monitoring and effectiveness of the controls being executed. Yeah, and that kind of goes right into my next question. You mentioned AI-specific risks like model bias and drift. Morgan, how can organizations adopt SOC 2 controls to address these risks? Yeah, it's a good question. I know Steve covered a few of these areas. I think Ultimately, like you mentioned, SOC 2 is really, really flexible, and it's a little bit of a weird spot too in the industry where you have such a variety of depth in terms of what is in one flavor of a SOC 2 versus one other provider's version of a SOC 2. And so I think thinking about things like processing integrity as one of the primary principles or criteria, and then even just thinking about confidentiality outside of security as a principle, AI provides a really unique opportunity to advise your clientele, the people that are going to be kind of consuming the SOC 2 reports, on some of the specific controls you have to secure those components or to make sure that processing is a key priority for you, that you've got, you know, data validation, data integrity controls kind of beyond what you might have in a traditional kind of processing ecosystem. And so if you're an organization that's working through that process, if you've had a SOC 2 in the past, but you want to introduce a new AI workflow or adopt a model as an example, it's really important that you do kind of consider those approaches. And so he mentioned about registry as an example. That's, that's a control really that might not take a significant amount of resource internally, but it can be tremendously beneficial in ensuring that you are actually addressing the problems that are inherent to an AI system. So making sure that you think about how are we going to use this data, where is it coming from, who's authorized to access it, et cetera. So when you think about taking that registry and compounding into other controls, that's really where I think organizations need to start moving in that direction. SOC 2 is so flexible that you can provide a lot more value externally if you're thinking about how to put those controls in place. And ultimately, that's where you're going to get the benefit from a model bias and a drift perspective. You can really put anything in the report that you want to within reason, but if you want to demonstrate a commitment to ensuring that your, your models are producing real accurate results consistently, it's important, I think, to go ahead, state those controls, make sure you're doing them appropriately, and a lot of that really comes down to the processing integrity side. Great, thank you. Another AI-related standard we want to talk about is ISO 42001. So this was, I believe, the first AI-specific standard focusing on ethical AI principles, governance, risk assessments, and life cycle management. So Steve, what distinguishes ISO 42001 from traditional security standards like ISO 27001 when it comes to AI governance? So ISO 27001 has been around for quite some time. It's well adapted, it's globally acceptable, and it's obviously a viable way for folks to demonstrate a certain level of maturity in their information security management program. Ultimately, you know, typically the ISO is focusing on information security. You know, the evolution of new technology, including AI, brings a different level of risk that includes information security. It's foundationally needed to be covered, but there's another level of risk that's, you know, much to what we talked about here with myself and Morgan, and we'll continue to talk about, that is really unique to AI. Right? So now certain elements, obviously there's always elements of governance, risk, and compliance that traverse many security standards, but a big shift with ISO 42001 is, you know, a specific management system standard designed around governing AI, right? And there's obviously emerging standards across different footprints as far as what's being put out there in order to do that. There's obviously global regulation and expectations that are being pushed up with, with the EU, and obviously even elements of focus here in the US. But that said, it's really look, ISO 42001 is really the standard that's looking to govern AI responsibility across its lifecycle. And of course, like any ISO, you know, you can go through the process of using the criteria as a benchmark to build out your program, but then you could also get a certification on it, right? So that's another element that could be looked at and focused upon and target for organizations are looking to demonstrate a certain level of compliance initiatives. Now, I mean, we talked a little bit about SOC 2 in that front from before, not to deviate here, but just to recap, the SOC 2 will handle much of what you need for purposes of your service level commitments and system level commitments. So there are sometimes differences in the scope in how you execute these different types of levels of assurance depending on if it's at an entity level, depending on if it's a system level. And again, if it's really predicated on specifically commitments you're making to customers. But if you think of ISO 27001 as, you know, the safeguarding of information and data, and then 42,001 is really AI using data safe, is it fair, is it trustworthy, things like that. So I think that kind of covers a little bit of the scope and the focus of these. But again, when you think about the risk orientation, you got threats, vulnerabilities, and security risk to data would really fall into ISO. There are those elements in AI, But then you have a broader level of risk with ethical, social, operational, and technical risks, right? And again, we talked about a few with bias or misuse or drift or anything like that. You're going to have policies and procedures that are going to govern this, in which you're going to find again in an AI management system are rules for these AI risk owners in this continuous monitoring, where there's an argument, you know, you want to make sure your security program to have continuous monitoring, but in an AI system it becomes even more important because there's a level of depth and somewhat a loss of transparency if it's not designed appropriately and it's not built out with certain types of monitoring behavior. So that kind of governance is expected to be in there. How you're retraining the data, you know, if you start to have biases or anything that's starting to come up with model errors or anything like that, model drift, how you're actually retraining those models and bringing them back in. And then of course, you know, any type of retirement criteria and versioning. So as models start to evolve based on, you know, subsets, information, and I'll call it tweaking— I don't know if that's a technical term— but modifications based on criteria and expected behavior, you know, you're going to want to be able to understand the output that's produced based on those. So those are things that would be captured, you know, within those AI kind of governance principles. And I think overall, you know, when you think of AI, its intended use is that responsibility, safe, fair, and explainable types of circumstances, right? So I'll wrap it up with an example. If you think about patient healthcare data, we want to make sure that of course it's safeguarded, it's securely stored, access and control and so on and so forth. If you started to go down, you know, all the ISO expectations there, but then add on to that and say, all right, well, if you're looking at it from an ISO 42001 perspective, we also want to make sure that the AI diagnostic models are accurate, that they're unbiased, they're explainable, they're being monitored for drift, any type of misalignment, and they're retired in an appropriate appropriate fashion. So I think that's really key there, and I know we'll talk about this later, but it's not one or the other. You know, some of the best programs are going to be predicated based on a collaboration of risk across both of these fronts. So a collaborative effort between these, these, these and more, which I'm sure we'll get into a little bit, will provide you with a sound, robust risk management structure for your, your AI systems. Yeah, thanks, Steve. And Morgan, you know, going off of that, how does ISO 42001 operationalize ethical principles in AI development and deployment? All right. Yeah. So I think ultimately, if anything, it's a bit of a North Star for organizations that are kind of coming into the space. So I think as everybody's seen with AI kind of seemingly coming out of nowhere, obviously it's not really the truth of it. But when ChatGPT burst onto the scene a couple of years ago, everyone now is, well, hey, look, I'm an AI expert or our tool has AI attached to it. ISO kind of met That Wave, along with a few other organizations to say, well, hey, look, let's provide some assurance around how we can meet these needs. And so we slowly saw the transition from kind of security constraints from just a general product security perspective into, well, we've got the ethical and social considerations to deal with, right? So if I'm supposed to rely on this model for an answer, how can I be totally sure that the output is reliable and it's not leaning one way or the other because the data is skewed one way or the other, right? So it's kind of get in what you get out of it, or put in, you get out what you put into it. So what ISO helps you do, especially as organizations that don't have a whole lot of that skill set internally, which most organizations don't at this point, is it provides you that guidance and the structure to consider some of those ethical and social dilemmas, right? So what are the kind of governance considerations that will force you to evaluate how is my model considering fairness, transparency, accountability, etc. from a data perspective. If you're not from a data science background, a lot of that is not going to seem super intuitive. You're just thinking, well, hey, look, I've got a model based on some given parameters and data, it's going to give me an output. All of the other stuff kind of around that, like how is my data sourced, what's the hygiene look like, is a little bit foreign for people. And so ISO helps, or ISO 42001 specifically helps to provide the structure around that, right? So starting with kind of having a risk-based approach. So how do we consider the controls that are built around our data and our pipeline? Similar to 27001, the data security component is always going to be there, but there are a few other considerations for ISO 42001 to, to deal with. And so that's really going to come in the form of your data acquisition. So building a lot of protocols and procedures around how you're getting your data, where you're getting it from. If you do transform that data in whatever way, if you're, if you're retraining your model based on what's already there, there needs to be kind of checks and balances, for less of a better word, or for lack of a better word, to make sure that everybody is very clear what's happening at that stage. And there's a number of reasons for that. It does help with, you know, things like model poisoning or data inversion, but ultimately it's also meant to prevent a model from giving an output that people are supposed to trust that's ultimately not maybe inherently accurate or represents bias, which is significantly damaging for organizations. We'll probably talk about this in a little bit, right? But it's not only that you want to get the best outcomes for organizations, especially in the healthcare space. If your model is producing outcomes that people have to take action on, as an example, or even financial institutions, the precedent maybe isn't quite there yet, but there's a very good logical trail to follow that if you're producing outcomes that lead to a negative impact for a certain party, there's a lot of liability to be associated there. And so it's not just kind of an ethical consideration, but even a business consideration that kind of needs to be understood. And so that's really what ISO 40001 does. It gives you that first step. Let's think about these problems and start solving them. And there's other, you know, maybe contenders in the space now. Idris has kind of their own mini certification as an example, and there's others that are coming about, but ISO was the first on the scene for sure, and I think it's done a really good job at surfacing those issues. Yeah, and some of those other, you know, standards you mentioned like HITRUST, so how do things like GDPR and HIPAA intersect with AI compliance, you know, especially in data-intensive use cases? Yeah, it's— the reality is there's a good bit of overlap, and I think it's interesting You know, if you start to kind of look around at things like job postings for like AI security architects or like chief AI officers, a lot of what they're looking for from a security perspective is more along the lines of people with like product security backgrounds or secure development because a lot of that kind of overlap in terms of how do we manage the security of the system, the frameworks that already exist that are part privacy, part security, GDPR is a good kind of example of that. Those requirements around having a baseline of a secure system are fairly consistent. It doesn't really matter what flavor it is. Again, NIST has, you know, 1,000 special publications. A lot of them deal with a lot of the kind of core common control areas. GDPR and the HIPAA security rule as an example are in the same boat. They have a lot of core controls around how do you secure your data, just all of that. The interesting part with, you know, HIPAA and the privacy rule and GDPR specifically is the use of personal data. And so, you know, with a lot of AI systems, that has become a really big, big concern, I think, for consumers and generally for businesses as well, is that you're— in order for your models to work, you have to have, you know, incredible amounts of data effectively. And so what that leaves you open to as an organization is a significant amount of liability. Think about like a regional provider as an example. They might have, you know, a couple thousands of records, maybe tens of thousands, hundreds of thousands. For the models to work in the healthcare space effectively, at a minimum, it's hundreds of thousands, if not millions of records for a lot of these large health analytic companies. And so just by nature of being in that space as an organization, whether you're healthcare or not, if you're taking in personal data in droves, there's a significant kind of liability associated there. And so it's really, really important that you do kind of align the controls that you have from a kind of an AI-specific or AI system-specific guideline basically inherently have to be aligned with HIPAA and GDPR, wherever your kind of local regulations are. Because if you're consuming that data, if you have a relationship with a data subject, as an example, you're beholden to those requirements anyway. And so that's— it's not like an option, right? So if you start to move into this space, you're consuming personal data. And if you're in healthcare space specifically, it's not a, it would be nice to have this, it's an absolute certainty. You need to have it. If something goes bad and you're consuming personal data or health information, they're knocking on your door and they will not give you any excuse, basically. So it's really, really important as you are standing up that function, if you want to get into the AI game, so to speak, and you're using personal data, that's got to be a priority for you. And it is a little bit resource intensive for sure. GDPR, especially if you're not familiar and you do want to operate in the European theater, there are very, very stiff penalties, significantly more than the US has if there is noncompliance that's observed. And so it's something you need to be very, very aware of. And for the AI systems, it can be a little bit more complicated too because of the data, A, and B, kind of the nuances associated with things like data pipeline, data acquisition. It's really just more opportunities for you to fail candidly. And so it's really, really important that you have that assurance and you've got the mechanisms internally to monitor how you're doing. Morgan, you make up some really— I mean, you allude to some really great points there that I think are important to maybe double-click on here. And, you know, you and I have both been around the cyber and information security game for a while, and history kind of repeats itself, right? And it's interesting to see in the evolution of how organizations have to deal with really safeguarding actual production data that may have private information, may have controlled unclassified information, whatever data classification, you know, you name it, and how organizations are going to be able to train their models and actually evolve to that. And when you think about that, you're expected through that, you know, 42,001 and that governance structure and taking into account all those risks in coming up with technologies and solutions that will allow for, you know, the tokenization of that information that would allow them to drive all the logistics and the guardrails that they need and the results and accurate results while leaving out personal identifiers or certain types of identifiers that would constitute the classification of the data. So I think you bring up a great point there. I appreciate that. Yeah, I do want to harp on the tokenization aspect of it too. It's massive. I think even agnostic to industry, we're going to see a huge boon there. That's a great callout. Anybody that's listening, highly recommend give that a deep dive. It's going to be really transformative, I think, for the AI space. Yeah, thank you. And Steve, can you walk us through how NIST AI risk management framework complements some of these other frameworks like ISO 42001? Yeah, sure. I think, you know, once again, when you're looking at an information security program, and you're taking into account all the assets and technologies you're bringing into that, it's important to have a flexible yet effective and complete program. And sometimes, you know, that's predicated on a combination of frameworks, not necessarily just one, right? So we've talked at a decent length on ISO 42001, you know, as obviously something that's going to provide a governance structure with policies and procedures and audit in the AI lifecycle. But then you get into something like the NIST AI Risk Management Framework, and the NIST AI Risk Management Framework is, is a framework that provides for risk management guidance around the use of AI. But really it's helping organizations and key stakeholders identify, map, measure, and manage these AI risks, right? So it almost becomes like a runbook, a flexible runbook for them in order to tactically execute on the proper control mitigation based on some of these risks that you would typically see at a prescribed and more granular level, right? So if you look at it from governing, mapping, measuring, and managing, and then you have the 42001, that's design, development, deployment, monitoring, and retirement, you have the combination of the governance, but then you also have a more tactical workflow around specific AI risk. Now, you could also— I mean, we could go on here, but, you know, another one that we typically will speak to clients about is really the OWASP Top 10 for LLMs. Now, that's a very prescriptive level of risk around LLMs, very similar to the OWASP Top 10 for web application security, where organizations and developers— and Morgan brought up a good point, you know, the developers and the SDLC processes become very important for the deployment, proper architecture, right coding and safeguards built into the process and not an afterthought. Right. So the OWASP Top 10 for LLMs is another great way to kind of dovetail into your overall AI risk assessment that allows for some prescribed technical execution of risk management, just like the NIST AI risk management framework. And again, coupling that with the governance structure of the managing and monitoring of the overall governance of the AI system to make sure it's reliable. So I think, you know, you typically have a culmination of different frameworks, if you will, that's going to, when you pull them all together tactically, allow you to execute and properly govern risk at the appropriate levels with the appropriate folks, by the way, because your discussions on risk management, maybe to some of the technical developers, may be different than the discussions you're going to have with overall risk communities or risk management groups within the organization. That are looking at risk not only from a technical level, but a non-technical business and operational level. Yeah. And Morgan, you had mentioned HITRUST a few minutes ago, you know, in addition to NIST CSF, you know, what role do HITRUST and NIST CSF play in multi-framework environments? Yeah, it's a good question. I think it, it's super relevant to kind of the general thread that we're pulling on now, which is kind of the more specific AI frameworks versus something that's a little bit more agnostic like HITRUST or NIST CSF. I think tactically what happens a lot of times is an organization will align themselves with one or the other. So they might be a HITRUST shop, air quotes, if they're in the healthcare space, or they might just be NIST CSF. I think what we saw that's kind of interesting is a lot of it's also driven by their obligations. And so in the last couple of years, really in the run-up to maybe the last, you know, 8 or 9 months, there was a big push, or at least maybe a big perception in the healthcare space, at least, that, you know, some of the cyber performance goals that have been published and like HICP 405 is kind of a rule set that's being considered that would basically provide a general baseline or a general understanding of what are some key security controls organizations should consider Those have been in place. They're just recommendations kind of at this point, or some organizations might be required to leverage them. But the big push was, well, hey, potentially just like programs, there's something called Promoting Interoperability that providers can go through to provide an incentive on the tax cycle to basically validate, hey, we're doing due diligence, we're taking care of our data, etc. There was a big push and maybe poking and prodding that HICAP 405 and the Cyber Performance Goals, as an example, would be other opportunities for people to provide— to get further incentives. So whether that's additional funding from the government or kind of tax breaks as a result of being in alignment with those. And so what we saw kind of in the swell from that was a lot of organizations started moving towards NIST CSF because CSF ties in very closely to both of them, the Performance Goals and HICAP 405. All that to say, we haven't really seen that materialize, but organizations typically are going to be aligned with one or the other as a result of either business commitments— HITRUST is a big driver of that— a huge chunk of people that are going for HITRUST from an organization perspective are being driven by business commitments. They've got a client that requires them to have HITRUST, so they're going to go and pursue that. What that means for a lot of organizations is they have multiple frameworks. They have to abide by, or they have to at least focus on. HITRUST is a little bit different in that it's certifiable, just like ISO would be. So you actually have to kind of— people have to check your work. With NIST CSF, it's not quite that way. It's kind of a framework that you'll align with and benchmark yourself against. So kind of across 42001 as an example, or 27001, which has been the more kind of general ISO standard, what organizations are working with now is leveraging those different frameworks against each other. And so there's been a huge push kind of in the industry in the risk space for kind of control harmonization is what people might call it, right? So taking multiple controls or taking multiple requests as an example against different requests and trying to alleviate the audit burden, because that's huge. Every organization knows you can only get poked and prodded so many times before you're like, please leave me alone. And so I think that harmonization coupled with toolkits like Drata and Vanta— they're really easy names to throw out, but there are other players in the space that are trying to automate some of that, that lift— are really important to consider. And the short answer is, you know, if you're satisfying several of the controls for 42001 as an example, or, you know, even HITRUST's kind of AI certification, and you are an AI shop where you have a model that you're building into a key service for you, using the underlying framework you already have, whether that's HITRUST or NIST CSF, can get you a lot of the way there. A lot of the controls are going to be kind of fairly agnostic security baselines, maybe more focused on dev security than some of the other frameworks might have been. It's really just that kind of delta where it's around, yeah, bias and data validation and data integrity that might be a little bit of a nuance there. But for every organization, I think it's standards are trying to bridge the gap to some extent, but there's always going to have to be a little bit of, of delta between them. And so it's just important for organizations to have a plan and leverage any harmonization they can between frameworks. Awesome. Well, thank you so much, Morgan. Thank you, Steve, for joining me. And thank you all for tuning in to the Risk and Cybersecurity Podcast. Don't forget to subscribe and join us next time as we speak more with Steve and Morgan on the drivers of AI compliance and your strategic options.