Name: Stand Out and Drive AI Trust with ISO 42001
Uploaded: 2025-03-26T15:30:25.724Z
Duration: 1 h 5 min 28 s
Description: Stand Out and Drive AI Trust with ISO 42001

Transcript for "Stand Out and Drive AI Trust with ISO 42001": Okay. Good morning and good afternoon to our audience. I know we have some joining from The US and some over here in EMEA. We'll kick things off in just a minute. We're just waiting for the more people to, flood in, then we'll get kicked off. Thanks. Hello to those who are joining now. We're just gonna wait another thirty seconds or so before we kick off, just to make sure we've got as many people as possible in here. Looking forward to today's session on forty two thousand and one. Super. Okay. I think, we've got a lot of people in here now, so, I think we're about ready to kick off. I am joined today by some experts from Drata, A-LIGN, and AWS. Not just experts. They're all old colleagues, old friends, so you'll see some of that chemistry, popping out during during this session. But what we're here to discuss today is 42,001. So firstly, we're gonna hear a bit about its importance in the context of its rapid evolution, its rapid adoption across supply chains, and also against the backdrop of a regulatory environment, particularly here in The EU, that is, that is ever changing as well. We'll then hear, from various perspectives, some practical tips on implementing an AI management system, an AIMS, and what to be expecting during an audit process, during that certification process that you go through. And before we wrap up and finish off with some questions and answers, we will hear about how SafeBase and AWS support companies in demonstrating trustworthy AI risk management practices. So looking forward to all of that, I think. Please, pop your questions into the q and a section of this webinar, and we will hear answers to those questions, at the end of the presentation. So without further ado, we'd love to have some introductions. So I am Martin Davies. I'm the senior audit alliance manager here at Drata. Still working closely with A-LIGN to deliver that perfect handshake between the software solution and the certification that that takes place leveraging that software solution. Tim, I'll pass over to you for an introduction. Yeah. So, Tim Sandage, I, lead our global and compliance acceleration program. It's a it's a partner led, partner driven program that helps various customers and partners get through regulated workloads across the globe on AWS. Thanks, Tim. I'm Patrick. I'm Patrick Sullivan. I serve in innovation and strategy at A-LIGN. One of my primary focus areas and the reason I'm here today is because I do focus on AI governance, AI safety, and AI compliance. Excellent. Thank you, Patrick. And Matt finally? Of course. Happy to be here, Martin. Thanks so much for guiding us through the conversation today. I'm Matt Hillary. I'm Drata's chief information security officer. You know, my team is customer zero here at Drata. We use the platform daily and for all of our, you know, certification efforts and audits. You know, I manage our internal IT security compliance and privacy teams alongside all the other fun aspects of being a a CISO at a security company. But today's topic is absolutely absolutely aligned with the objectives that I'm seeing across the board as I talk to many of my peers in the space. Super excited to share my thoughts today. You know, as a practitioner and also share this time with just two amazing individuals, Tim and Patrick, thank you for your time and contributing to the conversation and again, working for leading. So looking forward to learning from all of you. Super. Thank you, Matt. Looking forward to this session as well. Let's get, let's get right into it. Patrick, I think let's begin by exploring ISO 40 one context of the, you know, sheer breakneck speeds that it's being adopted across supply chains. Could you set the stage for us, Patrick, by highlighting its global relevance today against that backdrop? Of course. Of course. And so what we see, at least from our perspective today, is an environment where a couple of really strong influence are coalescing. The influence of confusion, and the influence of rapid change with a need for structured processes. And so ISO as an organization recognized that this this change was coming, that the tides were moving this direction. So they developed ISO 42,001, which is a governance and management system standard for the AI lifecycle. And so ISO 42,001, for those who aren't familiar, simply provides a process, a structure, a framework, if you will, for those organizations that are developing or deploying AI in some fashion to do it in a responsible and meaningful way. Ultimately, that is the value of ISO forty two zero one. Super. Super. And I think, Tim, building on what Patrick mentioned, I'm interested in in your perspective on, you you know, from a regulatory standpoint, how, you know, things like the EU AI Act and this concept of self assessing so called risky AI. You know, could you talk to us a bit about your your, insights there? Yeah. And kinda to, you know, to add to what Patrick said, I mean, this is something that, you know, we were looking around corners, saw this coming even for AWS because we're a customer obsessed organization. So we knew that our customers were gonna need that reliance from an AWS perspective. And so we just finished the certification earlier this year to ensure that it's a layered approach. And then to your point in question about the EUA act, we saw we saw the, you know, first implementations coming out and then the potential for a certification requirement coming out in August year. And then, obviously, what's risky AI? That's that's kind of the, you know, that's kind of the the scary part is, like, okay. What you know, it it's a it's a depend. You know, what's what's what's risky to you and an AI versus the other? And so our recommendation is is obviously because there isn't a certification path directly related to the EU AI act is that this just is a smart process to make sure that you have the right governance and you have the right, you know, capabilities so that when you're standing in front of a customer, they have some assurances that your product or services, whether it's in The EU or whether it's in The US or APAC, that, you know, they can rely on that you're at least using some layered security and governance model to ensure that your AI is effectively being secure and compliant. And, Tim, this is Martin. Martin, I'll turn it up. But, Tim, I think you've mentioned something very, very important there. And that's for organizations, We're all desperate to find a way to offer assurance to our customers. You know, the value chain is desperate for ways to ensure that we are developing and deploying AI responsibly. As of today, we have no conformity standard for the QMS for the EUAI Act, which means we have to rely on other mechanisms. First and foremost, ISO 42,001 shows that it can be implemented in the context of the organization in such a way that we can simply extend it to meet the needs of the specific market we're operating within. Yeah. No. And and and I think it's it's a powerful capability that our customers need to understand, and this is it's ultimately giving that assurance so that they can sell through products anywhere they're selling in the globe. And this is so important. Yeah. That concept, Tim, this self assessed risky AI, and I suppose this is a question to all the panelists, is there certain types of AI usage that you think are under assessed quite commonly in terms of their risk level? I think it varies. I mean, you know, we're we're seeing so many different use cases now today. I mean, everything from, you know, simple, you know, documentation automation, you know, even even, you know, building different parts and pieces and integrating into existing, you know, software solutions. So, you know but then there's the more advanced that we're seeing that's that's evolving every day. And every time a net new model comes out, you know, it's, it has more capabilities and and more, you know, touch points. And so we've gotta just make sure that, you know, that we have a good governance model. We can make sure that we're tracking, you know, what are the evolutions and the changes and, you know, that we're following that because we're gonna see this evolve very, very quickly. We already have. And and you're right. Absolutely. I I feel like, you know, that that's something that's gonna continue to evolve over time like you mentioned. Right? The more we learn, the more we'll more adequately assess that risk level. To your question, Martin, do you feel like they're under assessed? I don't know yet. I think the buckets that we have here with minimal limited high exposure unacceptable risks, those continue to evolve based off, you know, the use cases and outputs that some of these models are generating. And so it seems like we're trying to take a conservative yet a really practical balanced approach right now, and I think we'll continue to see that evolve almost to a point where they seem to be adequately assessed. I don't know if that resonates with you, Patrick or Tim, but, yeah. It absolutely does. And in fact, I think we'll see some of the risk categories, not necessarily the risk categories, but what systems are tagged in those risk categories of all over time. You know, right now from a high level, we've got these really ephemeral goals, democracy, rule of law, fundamental human rights. And we know in some ways how to connect those to empirical ways to measure. But what I think we'll see is as systems continue to evolve, we'll see that some systems that aren't currently considered high risk will be as we see them in play longer and longer, and they have an opportunity to have new emergent properties and new emergent risks. Yeah. Makes sense. I've I've seen some use cases where the AI is, is the final decision maker, and it's about what are the risks associated with giving the keys to an AI that is that is kinda making those those autonomous decisions. So interesting. Patrick, considering this and the and the regulatory backdrop, how reasonable or practical is this framework for companies right now? So the consultant's answer is it depends. I will I will say that ISO 42,001 is a management system and that's hard. And so those of you that are familiar with other management systems already have a concept of what the framework is. ISO has done a really good job of formalizing what they call their high level structure. That is the management commitments, the clauses that every organization must commit to from the top down. And so from a reasonable implementation perspective, what you'll find in forty two zero zero one is that it's simply asking your management to think responsibly and holistically about the things that happen through the AI life cycle, commit to good planning, commit to providing resources necessary to ensure that the aims can function, and then commit to continuous improvement. So from that perspective, Martin, this is really a very straightforward thing. The reality is that the nuts and bolts, you know, as we start digging in to the unique context of every organization, you'll find that every organization is different. And that's where I think Drata really shines in providing a platform that allows organizations to marry their people process to an existing technology to ease that transition into implementing their names. Great. Great. So thanks, Patrick. Matt, we touched a little bit there on compliance, this concept of an AIMS and what that really means. Beyond this, what are some of the core principles that organizations should embrace as best practice, when it comes to AI usage? Great question. I like this question because it forces us to take a step back from looking at what bare bones compliance requirements may force us to look at. I I love that every organization out there is on their own journey. Many of them continue to stay, hey, resting on the laurels of what the compliance requirements require. And then, you know, sometimes just stay there. Many of us wanna look beyond that. And I think some of these things, especially with ISO 40,001, we are seeing some aspects there. I'm also seeing this with, even AWS's j d Gen AI. I think Tim may talk about that a little bit later, but the Gen AI competency for focusing more than just the compliance aspects and even focusing more than just the security aspects of running a capable AI model. And I'm loving that it's forcing us to look again beyond just those requirements. You know, many of these are really trying to focus on, again, looking at things like transparency, ethical use, the training of the models, the confidence in the models, again, security, and then just making sure, again, these are things that we can trust and embed and build the trust in our customers who may be using these capabilities. One of the things that we started with here at Drata, and that was something at the very beginning when we decided to add AI competencies and capabilities in our platform, we're, hey. We wanna give our customers the toggle, to turn on these capabilities. We do that today. You know, we don't just enable these AI capabilities on our own and say, hey. All of our customers want this. Let's enable this today. We give that toggle to our customers. They have to go in and configure and say, n a enable AI capabilities. And we have a pretty extensive blog post on how we make sure that when we do enable these things that their data are not retained, that, you know, customer data elements are not used for future training there. They really are in the hands of our customers. Now I'm seeing a spectrum for all organizations. Many of them are like, oh my gosh. I wanna adopt all the AI things today. Anyway, I have a spectrum on the side other side of the spectrum, which is like, no. We can't touch any of this stuff yet. We do not yet have the risk assurances that we require yet today to even start using these by our team members or by our organization. And so we do the as a SaaS provider platform, we, again, put that key in their hands to then enable that when they feel appropriate to do so. And at the same time, give them the appropriate artifacts, certifications, as well as assurances that what we are doing behind the scenes mirror what they expect. So that was the first one is, again, giving them the key. Next up is just being transparent. Right? I feel like even at a personal level, the good kind of vulnerability between two humans really helps establish that connection or relationship between two people, same with organizations. And so when it comes to our use of AI, you know, our recommendation there is to be as transparent as possible. I think many of these frameworks are having us basically just explain just like we would during customer due diligence process saying, can you show us an architecture diagram of how you're set up? Well, adding AI capabilities into that story really helps build that transparent to say we are using AI in this capability. We have our data elements here. These are the data elements that we train with. And, you know, these are the third parties that we may use. So at that point, it really is helping build that foundational aspect to help build that trust in our SaaS platform as well as any of those out there. We just need to be upfront about what models we're using, what algorithms, whether it's a chatbot or some kind of decision or recommendation engine, just making sure that it's very clear to the end user that AI is being used behind the scenes to help provide that information because we're still in a state that we need to verify the output that is being provided in many of these cases. Again, just hitting again on transparency. We just need to be open about how we're using it, what systems are used, and others. I was gonna jump on ethical use. Right? I think this is the biggest concern across the board is, hey. How do we make sure that, the models that are trained are trained with without bias, reinforcing that kind of systematic equality across the board and fairness and nondiscrimination. You know, this comes from making sure the datasets are clear from these biases, but also making sure that we continue to test those models and improve those models just like Patrick Sullivan said before about, hey. You know, we wanna continue to improve our AI management system. That applies trickling down to our models that we're using to make sure that we continue to improve those. Last but not least, just wanna make sure that we're using AI in a way that positively impacts people, you know, avoiding any harm. I think that's been one of the fears from the outside by saying, oh my gosh. How do we make sure that people are not using this in a way that may not be, appropriate? We're not yet at a point where we're allowing autonomy with these. I think, in general, it's still gonna be humans herding these bots, if that makes sense, to make sure that we are comfortable with the output that they are providing to us over time. I think about even the audit. Right? You've got our internal GRC team members that are gonna be armed with these capable AI models to help manage a really well capable GRC program. And then you've got our auditors, our assessors that are also trying to look into training models to help show up to audits as the auditor. And so it's gonna have this box against box type of potential future here, but the reality is is there's still humans, creative elements there that are making sure that we are going the direction that we want to go in both of those sides of the table there. And I think it's gonna be exciting to see how that enables us to be able to do more than we're able to do before. I know we ultimately want to trust these models, so I wanna touch on confidence and reliability. Ultimately, we want these to be able to be helpful in a way that we can rely on those. So continuing to build that trust over time. I am seeing many red teams today as I attend many of these AI cybersecurity conferences. Many are coming out with dire con concerns about, hey. There really is no way we can secure all the inputs and all the outputs, and so we have to be kinda worried there. But at the same time, still putting in the right efforts to, make sure, again, these are trained well and and protected against, you know, concerning things and outputs that might, harm us. And so that's, again, another part around the reliability aspect. Last but not least, security and private. We still need to be, you know, clear about the data that we're storing, transmitting, and processing from end to end, you know, from a privacy by design standpoint. Just making sure, hey. The data that we're providing and handling is very transparent and clear with the purpose of handling. And then a security standpoint, we still have to secure this infrastructure that many of these things and capabilities are running on, you know, patching underlying vulnerabilities and securing misconfigurations. And so when we look at a security layer, there is a lot there that that many sometimes will neglect, especially when we started using AWS and large cloud providers out there. Many organizations neglected to secure that layer just as much as they secured other layers in their stack and led to some pretty dire consequences for those organizations. And the same is here with our capabilities around AI is making sure that underlying infrastructure, cloud service providers, other So I know that's a long answer, but I hope it was insightful. Mostly just Hey. Where do we go beyond just compliance? Those are some elements that we'll consider. No. That was great. Thanks, Matt. I love, bots bots against bots as well, coming to a cinema near you. That's I love that concept. I suppose on the flip side, Matt, right, you mentioned a lot of certain things that that should be considered. What are some of the risks that organizations might face, in your mind? I guess, firstly, we have some of those internal risks among the team members who might be using AI models, but then broadly, taking a step back, the risks that companies face when embedding AI in their SaaS platforms or or their cloud environments as well. Yes. I have a follow-up question because I use I I as a seesaw, I view this in two different ways. One is our internal use of AI by our team members. Again, that's that has its own set of risks. And then the second is as a SaaS platform built on capable cloud providers like, hey. The use of AI within our platform. I think I address those two different ways and, love to hear from, you know, my practitioner friends in the space as far as, like, what they're doing. As far as use by, you know, use by our internal team members, this is where I think organizations are still trying to decide where they want to enable their team members. Some are your hybrid model where they're like, hey. You know, anything goes. You know, use user are going to I I'm not seeing that as often, honestly. I think many are saying, hey. We have an enterprise account with this LLM provider, or we have an enterprise account with this platform. Please use those. Those are the only ones that are authorized for use internally to put any of our information above internal or confidential into those spaces, because we have that trusted relationship with those providers. I think that's what I'm seeing more than not. I'm also seeing many organizations be practical about it because I think we're still putting a price on the use of AI, and in many cases, that price tag was very, you know, clear when, you know, I talked to many of my peers saying, oh my gosh. Like, this provider that we're using, they added this AI add on and this is how much it costs. And we're like, oh my gosh. This is way too much for our organization. And so they're like, oh, who actually needs to use this? And so then they're kinda like siphoning that down to, like, hey. What's your business need? And they're paying for that. Again, just to be practical and a good use of, you know, company's money there to help enable our people because this is a great enabler for all of us. I use it daily in a number of facets. I've rerouted using search engines to using AI first, but then obviously verifying the output before taking accurate. So, yeah, the shadow IT is a real concern. Right? And some organizations are gating that really hard with some really capable platforms that on their endpoints are saying, hey, if you hit, you know, this endpoint, it's going to redirect you, your local instance, to our approved version for this use of this LLM to help again protecting almost it sounds it sounds draconian, but forcing that kind of redirection to a platform that, again, is really trying to help our end users feel confident. So I see the utility and some organizations doing that so that they can make sure that all use of capable AI by internal teams is routed to what would be, you know, acceptable for that company. So a lot a lot of points there, Martin, but, I can keep going, but I I think that was the internal side. I'm happy to talk about the SaaS provider side, but, there there's a number of things there on the on the SaaS provider side that I just talked about, in in various facets there. But yeah. That's great. No. Thanks, Matt. Patrick, Tim, I wonder from your perspectives, you know, what what are some of the key risks that you see out there? Yeah. And and Matt kinda touched on it, and it was exactly what I was thinking. He kinda stole my thunder. So thanks, Matt. But, you know, but, yeah, we're we're back kinda in that in that era that we were seventeen years ago with Shadow IT. Now we're Shadow Shadow AI. And so we're seeing you know, I mean, just look at it in the most basic layer. Go out to a, you know, Google and prompt it. So for something, it comes back with an AI response. But go further into, you know, the use cases where organizations are saying, hey. I can get my I can get more efficiencies by going out and, you know, leveraging this public AI in a corporate environment. So that's where, you know, you obviously have to see organizations need to, you know, address that, make sure that their security policies and procedures on. And and so we're, you know, really back to that beyond compliance, like, what Matt was saying is it we're kinda in that point where, like, hey. Let's make sure that we're putting the safety, security, and compliance, and privacy elements, you know, at the forefront of this, especially in a corporate environment where, you know, you've got, you know, human capital that is trying to get their work done faster and better and more efficient, but may not understand the impacts to the organization themselves and their customer base by not necessarily using this in the most, you know, secure and compliant matter. So it's it's just trying to help organization. Then that's part of you know, Matt also touched on this too is that we work with our customers. Like, okay. We'll make sure that as you're integrating these services within your AWS account, make sure that you're following the same hardening principles and the same security principles and the same, you know, processes that we've been working with our customers for years on on how they integrate our AWS services in their customer account. And this is no different. It's like you've gotta make sure that all those parameters and security, you know, approaches are and then and then possibly lean into it farther. It's kind of the old adage of, like, you know, put sequence in your car before they're required. You know, put safety mechanisms into your AI before they're required because you're gonna it's looking and we really ultimately end state is that we review, you know, we kind of view compliance and security with business enabler. You know, as a customer of AWS using cloud, if you can go in and and illustrate that you're beyond what the, you know, the norm is from a security and compliance capability, it becomes a selling capability to you as a as an in state, you know, partner on AWS. And so that's the key message is this is going to keep you from getting the objections during the sales cycles. Well and what's huge and honestly, before I say this, Matt, I kinda wanna hear you riff some more. So I'll I'll be brief. Okay. Tim, as a follow-up to that, one of the things that's really important for organizations to understand is that when you employ when you operationalize your management system, in this case your aims, ISO management systems have no mechanism to carve out vendors. They have no mechanism to allow you to inherit vendor controls. You as an organization will continually and constantly retain accountability for ensuring appropriate controls are in place throughout your AI life cycle. And so as Tim talks about this relationship with trusted vendors like AWS, with trusted vendors like Drata, those relationships become so critically important because you as an organization have to continually ensure that the controls that are being employed on your behalf through these trusted partners are adequate and reasonable. So that that responsibility never goes away. And so research on the front end, continuous integration, continuous conversation through operation are absolutely required, and you need to ensure that you have partners that are willing to step up and actually walk the path with you. Brilliant. Some really good insights there. Patrick, staying with you for a second from a practitioner's perspective, we've all all on this call, you know, everyone in the audience, I'm sure as well, we've seen ISO 27,001 and SOC two, grow rapidly in in recent years. What insights do you have in terms of the similarities between these frameworks and 42,001, particularly in the context of risk assessments? Yeah. It's a really, really good question, and it requires a little bit of an extended answer, so apologies upfront. So what we see with ISO 27,001 and SOC two, type two in particular with appropriate TSCs, Even AICPA produces a mapping document that shows us about 60% of controls or cross applicable between twenty seven thousand and one and SOC two type two. In that regard, we see really focused representation and assessing risk around those things associated with security, which is the focus of ISO 27,001 and SAW two type two with the security trust service criteria. So we see a lot of harmonization between those standards. What we see with 42,001 is something very, very different. With 42,001, the concern isn't necessarily security. In fact, 42,001 has a limited view on security. It's focused on responsible development throughout your AI life cycle. To that end, however, there are some connections as it relates to risk. Specifically, two areas have been added to ISO 42,001. It'll be net new for a lot of organizations in that, orgs must create an AI specific risk assessment process and an AI specific impact assessment process. And so that risk assessment process will see focused on the AI system or systems that have been deployed and are being governed by the AI management system inside the organization, but they will be focused to those systems. This can supplement and support what's going on with enterprise risk as we might have produced through twenty seven zero zero one or your SOC two, but they're not the same thing. We can't simply say my enterprise risk also assumes some AI controls. That's not the intent of forty two thousand and one. We have to think in context of our system as deployed in the environment, the specific impacts that might befall our internal and external stakeholders should we have an issue, and the specific risks associated with deploying the system for both internal and external stakeholders. So it's important to maybe package it a little bit neater. It's the same only different. We do have a risk component of forty two zero zero one, but it's very focused and very targeted to supplement and support what organizations are already doing with their enterprise risk. That's great. That's great. I like the short and sweet answer to to kinda compliment what you said there. But I suppose I've I've kinda heard it similarly described as, you know, the enterprise risk assessment process is a muscle that you exercise, but, you know, there's very specific, activities that you're doing. And when it comes to AI, it's it's the same muscle. It's the same concept of, ownership, governance, accountability, but the subject matter is that much more laser focused on on AI. Right? And it is that's more and that's exactly right. Perfect. So shifting gears slightly, you did mention some some tips here, Patrick. But what I suppose two questions. What advice would you have in general for someone implementing in AIMS? And then how does ISO 22,989 factor into, you know, supporting the creation of an aims for for people who might be doing this for the first time? Oh my goodness. So the first recommendation, and this goes for every organization anywhere in the world, by the standard. This is something that can be frustrating for people, but ISO does require, the standard to be purchased. It's a couple hundred dollars US. By the standard ISO 42,001 so that you, in your own words, in your own context, can have an understanding of what it is you expect your organization and your management body to make legitimate commitments to. So that's really where everything begins. From there, what you're gonna see in 42,001 are links out to several normative references. These are documents that refer to other standards, other ways of doing things that are a little bit too verbose to be included in 42,001. So 42,001 simply references them. As an example, you'll see the normative reference for AI risk management, ISO 23,894. What that means is as assessors well, let me rephrase this. As you are building your AI management system, when you get to the point where you're beginning to plan in clause six, what your AI management system risk assessment process should look like, ISO says, hey. 4201 is gonna be silent on this, but check out 23894. It's gonna give you everything you need. So there are these strong linkages between the standard itself and normative references that are used to support the standard. ISO 22,989, this is a lot of numbers and so are everyone, is critically important because it sets the stage for vocabulary. And so when we say AI, what does that mean? When we say machine learning, what does that mean? This could mean different things to different people. ISO says, look, we've got the source for all vocabulary as it relates to AI and or standards, and they're documented here in ISO two two nine eight nine. Now what's really, really interesting as we think about scoping, as organizations think about scoping and really articulating their context of how systems are deployed, AI systems are deployed in their ecosystem, is that when we start articulating our context, we have to think a little bit differently. In that, we have to determine our role in the ecosystem itself. And what ISO says is, hey. Generally, we're gonna have one of three roles that organizations provide. Organizations can be producers. These are the forms like Microsoft, like OpenAI, like Anthropic, that are actually producing the LLMs or services that are sold downstream to the next role, which is providers. And these are organizations that consume services for the purpose of delivering value to customers. Next, we have customers or users. So those roles, really one or a combination of those three roles, are generally assumed by an organization as they're clarifying their context. And this becomes so important because the role that you play in your environment helps you understand potential impacts. Should there be issues, potential risks, should you have failures? And also really understand where you need to focus the controls to bring to bear to ensure that you are in fact developing and deploying AI responsibly. So two two nine eight nine is a critical document. And unlike the other ISO standards, it's free. We actually can provide a link to, ISO's free resources. It's one of the standards documents that any organization can download simply by following the link. So recommend everyone after this call do do just that. Great advice, Patrick. So ISO 22,989 for everyone on the call. You too. Yeah. Patrick, I think it's a real nice segue here. We had a question come in just on something you were alluding to there. We'd love to get some insight on what counts as developing AI. Would any custom AI implementation count as development or is developing AI specifically applying to training and developing and building these AI models themselves? So yes and. What I would say is look at two two nine eight nine. In that, what we'll see is that they are actually producer, provider, and user are really umbrella roles. And so for producers in particular, we'll see, AI developers as a subcategory. And in that, the developer can take on that moniker, that term based on a number of different activities. It can be training. It can be actually deploying into an environment for a user and then walking away. So there are a number of actions that can cause one to take on the role of developer. Ultimately, if you have questions about this, take a look at two two nine eight nine and walk through your scenario to see which bucket you legitimately fall into. Great advice. Thank you, Patrick. Matt, tools, as we know, play a critical role in a smooth implementation and maintenance of frameworks like this. Walk us through a bit how Drata and its templates and various other features, can guide and support organizations on this journey? Of course. First of all, just Patrick, thank you for all you just shared there. That was, I just love the recommendations, the insight, the knowledge, even just as a person in this space, love learning from you. Thank you for that. And Tim as well to already so far in the conversation. So, you know, we're all learning new technology, this technology specifically, and how to secure it and how to, you know, comply with the underlying standards. I love the recommendation to go get the standard, read it. One of my favorite things to do is when a new standard comes out is to literally print it out even though I probably should just do it on my computer, but then mark it up almost like you would, a biblical text You don't know how to write it. Yeah. It's like we're we're learning a new kind of way to approach this. And so great recommendation there. I did that as well. And, you know, Drata is a platform and as an organization, we aim to meet customers where they're at on their journey. And so, you know, being customer zero here at Drata, we're also on this journey. You know, we truly try to help organizations, you know, help jump start that journey as well. And so just like as you mentioned, alluded to there a second ago, Martin, we do have these templates. We do have, you know, these controls that are in our platform. So today, our platform does support ISO 40,001 and that journey. You know, I love that this particular framework is another way that the security and compliance teams inside of an organization can partner with and influence another part of the organization. I think I learned this at AWS where Steve Schmidt was like, Hey, we don't necessarily own things within the security department. We influence the organization broadly, and that was one thing that was helpful to understand to say, hey. You know, while many security teams do own many things and while the compliance team does as well, the greatest part of that is the influence on other parts of the organization. And so what a great opportunity for GRC teams, for security teams to partner with their data teams, their AI teams, any of the parts of the organization that touch the standard to really help mutually grow together to the point that we really are meeting the objectives together. So this is gonna be a really fun collaborative exercise internally. So speaking about Drata specifically, at the core of Drata platform is we do have our Drata control framework or DCF. It is a common control framework like many out there. We do support many customers who come to the table with their own common control framework to help map to what's inside of Drata. But, it makes it really easy and like you mentioned, like, hey, what are the differences between SOC two ISO and then jumping into, you know, 40,001 or other frameworks is there's a there's a ton of commonality. But like Patrick called out, here there are many new common controls that we had to add as a result of, you know, many of these specific requirements within the standard. And so it's very cool to basically see this additional aspect that we need to learn together. So as a result, you know, with, the AIMS and the supporting, you know, antech controls, we have a section within Drata that helps support, hey. What attributes do we need to put in that AIMS? And then the second half is around the specific controls that we need to address as part of that, and those are mapped to control tests. Those are mapped to controls that we need to meet. You can view the framework from a framework centric view, which is like, hey. I wanna see what the framework says and the controls there to then implement those. Or if you wanna map to the common control framework, you can view it from the con the common controls there to see what is needed to be met, and you can start attaching evidence, artifacts, policy. I think one of the main controls that it wants to have us implement is an AI specific policy. Going beyond having, like, an acceptable use policy for internal people to use or internal team members to use AI, this one is a AI policy, which is very comprehensive and supportive of many implementations across the board. But, you know, all of these, you know, generally help all of us, you know, get ready for to do that kind of gap assessment that you would want to see where we stand, create that kind of tick list of items or things that you need to go through and remediate towards getting ready for your audit. We also support, you know, via our audit hub, the ability to have a strong conversation between internal folks and our assessment organizations that assess us to help make sure that conversation is very, very smooth and pulling the respective evidence to support their assessment. And last but not least, and this kind of teaser to talk about our trust center later is all of these efforts being able to be displayed on your public facing trust center so that, you know, an external organization can go in and review where you stand, where you're at, and, if they have any follow-up questions for you. We talk about trust center stuff later, but that's how Drata supporting end to end that whole journey specific to this framework. That's great, Matt. Thanks so much. Building up a little bit of suspense for what we want to talk about next on the trust center side of things. But before we get into that, from your experience at AWS, are there particular types of organizations or supply chains for which ISO 42,001 is especially relevant from what you're seeing right now? Yeah. And and kind of, you know, to the earlier point that we made is that, yeah, our customers' use cases are are very broad, and then we have, you know, of course, obviously be us being an infrastructure provider, we have a lot of platform providers and a lot of SaaS organizations that build on top of AWS, and then they're, of course, then, you know, selling to the next layer. You know, their customer their platform may be selling to a SaaS, and a SaaS may be selling to an end state customer. And so it's trying to help make sure that that, you know, more or less, the security chain of custody is in place. And that's kinda what our program was was developed for was to not only, you know, advise our customers on the different paths and the different responsibilities in the shared responsibility model between ourselves, you know, and partners that are that are servicing and customers is what is the responsibility of each layer so that there's insurance that, you know, that AWS is doing this as the infrastructure layer or even the pass layer for some of our services. But then our then our partners and customers that are building customer facing, you know, tools and services that are also then being utilized by in state customers, that they can kinda map all the way back to that. And and as Matt said, the, you know, the the most important thing is, you know, is this that transparency showing that, you know, that's why, you know, especially the, the trust centers and the things that have come out in the last few years are being able to say, again, as a business enabler, compliance and security is, you know, a primary use case of saying, you know, I'm secure. I'm following a rigid governance. I'm following a rigid rep risk management process, and here's the certifications that I have, you know, that support that. And so that's why we have a mix of, security and compliance advisers in our program, a mix of, you know, technologies, like Drata, and then a mix of auditor organizations like A-LIGN that we can rely on and say, okay. How do we help our customers and partners go end to end with this so that they're really able to enable themselves to sell through securely and with confidence to those in state customers? That's great. No. I like that, Tim. So, Patrick, Matt alluded before to, you know, draft this functionality when it comes to the audit hub. Customers who use us for forty two thousand and one, a lot of those artifacts, that audit evidence is is easily presented to A-LIGN as an auditor. And I already I know you've you've got quite a few 42,001 certifications under your belt as an organization already at this early stage. But to the audience that we have here today, what can they expect? What does a 42,001 audit look like? What what sort of tips or pointers would you have, when it comes to this? Oh, goodness. First and foremost, be ready. I think I think that goes without saying. But no. To to take a step back for those that haven't necessarily experienced the management system audit in the past, it's important that you understand that ISO really breaks out how we evaluate what you've done and how you've operationalized your management system into two separate phases that they call them stages. So you can expect your audit, when you're ready for external audit to be broken up as such, first of all, stage one, we as an organization, as a certification body or CB, will evaluate essentially the implementation of your management system. So this is largely a review of the policies and procedures that you have in place to ensure that you have in place those things that are called for by the standard. In other words, the standard clause five leadership says one of your outputs will be, an AI policy. So during stage one, we evaluate that all those things that are specifically called for are actually in place. But that's not good enough. So evaluating that you have documentation in place is one thing. And should stage one go well, we'll then schedule stage two. And stage two is where we evaluate not only design, but implementation and effectiveness. So you've said that you've done this. Now show us. You've said that you have an AI policy in place that you've trained your users on. Show us some evidence that this has actually happened. And so at the end of stage one and stage two, after you're validating that you have an appropriate structure and appropriate documentation and that that structure of documentation is effectively implemented, we'll talk to you about where we see gaps, where we see potential opportunities for improvement. And if the evidence is sufficient to warrant, the certification body will then issue a certification. If at the end of that stage two, you're not quite there, you do have an opportunity to perform corrective action or remediation and show us that that corrective action or remediation has been done to help us get to a place that we can feel, we or any other CD that is, can feel comfortable actually issuing a certification. Now, certification in and of itself is the start of the process. ISO management systems actually carry a three year cycle wherein year one, you go through a full assessment, stage one, stage two, to validate that everything is appropriate as it relates to the requirements of the standard, that everything's been operationalized. In years two and three, we perform what are called surveillance audits. These are an opportunity for the certification body to verify and validate that continuous improvement is in fact happening with your management system. So there's opportunities for improvement year one. In year two, have you actually done anything with these? Are we actually doing the expectation of the standard, which is the plan, do, check, and act, continuously improve over time? Years two and three are the mechanism to ensure that that's happening. So every three years, you'll have a full certification, stage one, stage two. In the off years or the the two years after full certification, you'll have an opportunity to show your certification body that you are in fact continuing to mature this AI management system so that it continues to evolve and grow with your organization over time. That's great. It's similar conceptually right to the ISO 27,001 audits with those different stages. And it's I can't do that. It's the underlying subject matter that that's, that's different. So that's great. That's really useful, Patrick. Yeah. Super. Alright. Moving on just before we go into q and a. So Matt did allude to this before, but safe base is, top of everyone's mind right now. So Matt, you can talk about how, you know, centralized trust centers and things like this play a role in managing and displaying that, AI government, governance, sorry, that a lot of a lot of organizations have, put a lot of hard work into. Of course. Yeah. We're super excited about the SafeSpace acquisition. Incredible team. Incredible product. Just incredible way to help bolster and show the work that we've been doing as organizations. You know, building and maintaining trust of customers really is the culmination of all we do on security, compliance, and privacy teams. That is the output as a result. And so no better way to showcase that to customers than via a trust center or a customer facing, customer centric way of sharing all of these documents, artifacts, or additional customer due diligence information. And even, I think, Safeway supports a q and a feature, which I've used and enjoyed seeing questions come in from customers to say, hey. I read all these artifacts, but I have this. And it really allows for a very efficient way of getting the knowledge that customers need to make a decision on whether or not to use the platform. And I've loved seeing that as a way to help, you know, in a very self-service way from a customer standpoint, be able to get the information they need to make a decision. And so, as a result, you know, just thrilled to have them join the team, their amazing team, and and and joining forces together to really meet all of our customers at the enterprise layer, the enterprise market, the mid market, and then as well as small businesses to really earn and enable that trust conversation. You know, just like we can add badges to our trust center, for various certifications or attestations, we can also add, you know, AWS competencies, which I think is really, really cool. I think you mentioned this earlier, Tim, and then even Patrick saying, like, as peers and friends and as partners in this space, we really do drive each other to be more secure, more compliant than ever. One thing that AWS does that I really, really enjoy and love is, you know, being a former Amazon blooded AWS team member is you really set those standards high, both A-LIGN as well as as AWS aside, where you really are helping, you know, organizations grow on their journey and not just rest on our laurels of whatever that may be. And so you can add those, badges to, your your your trust center today. You know, at four two thousand one, we have the ability for customers to display their certificate as well on their trust centers to be able to retrieve and review. And one of the coolest things about a trust center is you really are able to justify to your organization the efforts of a GRC team. You're able to go and kinda see, hey, two things. One is from a strategic standpoint, you can see what artifacts customers are requesting. So you can continue to support those, update those, keep those fresh, know exactly what the needs of your customers are so you can be more strategic about which things do we continue to maintain compliance with, which things are customers really caring about from a, you know, certification standpoint and using our own SaaS platforms. And so that's very informative for a GRC team to make sure they're focusing their potentially very limited resources on what matters the most. The next one is just around the secure way of disseminating this information. It's so nice to have a click wrap kinda NDA experience whereas if a customer does match and we recognize that customer within our CRM and they have a valid NDA, they're able to jump right in, pull the artifacts and then, in a very self-service way, get the answers that they need. Last but not least, but super excited about this is where, you can marry the efforts of the artifacts being pulled by customers with the associated revenue impacts that that might have. To be able to answer the question, hey, how much revenue did our GRC team impact or influence as a result of having these artifacts on our trust center? And it's really helpful to be able to communicate that number internally over the prior ninety days or the prior year to really say, wow, GRC is an enabler. GRC really is a differentiator. GRC is what's powering our deal cycles and our customer trust and moving forward together. As a result, I just smile and and really, really happy to see those efforts. Now, the very end part of that is many of these artifacts on a trust center are, you know, many of our customers still have questions and they'll send over questionnaires. Many of these artifacts trust center can be used to then with a capable AI model, populate answers to those questions in a very effective way to, again, reduce time on the other side of this whole trust center coin, which is continuing to like due diligence on third parties and answering those questions as we move forward there. So excited about, you know, the the invent of, I guess, trust centers in general. Largely because I was thinking about GRC and I almost wanna add t to the end of that because the culmination of our efforts really do does yield this, building and maintaining trusted customers in a very, very secure and, capable manner via a trust center. So yeah. Perfect explanation, Matt. I think, yeah, we're all really excited. It's cool to see that mindset shift of, you know, it's it's now a value generating there's an ROI associated with with all this, with all this compliance activity, unmeasurably so. Tim, finally, from AWS's standpoint, let's hear your thoughts on how 42,000 one's principles are inherently supported, within your cloud services. Yeah. And and kinda going back to that to the inheritance piece of, you know, again, we've gotta make sure that we're showing that we're leading the, you know, leading the charge of having the AI governance in place because as goes back, I've been with AWS a little over twelve years, and I can over the years, we've we've basically listened to our customers and looked at what are the certifications that they need looking around the corners of, like and it started out at the at the ISO and the SOC ones and the SOC twos and then FedRAMP and DOD and and over the years. And now you look at our our compliance page, and it's pretty it's pretty amazing to see the level and depth of different certifications that we have across the globe. But that's all based based on our customer obsession is we get that certification so we give reassurance not only that we're operating properly and and, you know, looking at the ways that we support our customer base as well as also back to some of the things that Matt Hillary said. You know, building that transparency, you know, that customer trust and putting things out there that says this is what we're certified in, and then this is how our customer then, you know, layers on top of that, you know, for their, you know, customer facing SaaS or PaaS or or whatever the case may be. And then kind of back to, you know, looking at the evolution of things like SafeBase, you know, is is a lot that people know or maybe they don't know. We came out with a similar thing for AWS specific, which is Artifacts several years ago. And, again, that really opened up the doors for our partners and our customers to understand how does AWS do securing compliance, and what are the reports that I can rely upon? And now there's a self-service portal, you know, within AWS from from our standpoint, as well as we've got, vendor insights on marketplace that then now also maps and then this SafeBase. And I just I can't, you know, say enough good things about Drata, you know, acquisition of SafeBase because this has been something that our partners and customers have been using quite a while now, and they're really seeing the opportunity of of how does this show what their, you know, certifications and and reports are and having them freely available. So this is really you know, it's part of that transparency journey that we've been going through for many years in the cloud is is, you know, how can I how can I ensure that I can rely on the infrastructure, the platform as a service, SaaS service, whatever the case may be that's built in the cloud? And then, you know, going back to and we've kinda all touched on this. Is it truly security and compliance as a business enabler? And Matt kinda alluded to that as it we do a lot of that as what are the what are the customer opportunities? Does a compliance or a certification outcome what does that do to drive, you know, revenue either for our customers or for our partners and so forth? And so there really is an impactful ROI on compliance nowadays. And so it's no longer a, you know, a draw on the business. It's actually a business enabler. And so making sure that you have those metrics and you're able to show that enhancement of how it's driving the business because you do have this transparency and reliance and security capability. And for the buyers out there That's a great question. And Martin, I was just gonna say for the buyers out there, it can be really hard to hear and understand what both Matt and Tim are saying until you don't have those things. And so it's akin to the windshield on your car. You know, that's something that we very much take for granted, but imagine doing 60 miles an hour down the highway with no windshield. Suddenly everything hurts. The same is true when you consider partnering with a vendor that can't offer you a real understanding of what controls are being employed and the services you're consuming or a mechanism for you to offer to prospects and existing customers the assurance that you're doing the right things with their data when you've done all the hard work already. So these two tools between what AWS is doing and what Drata is doing with SafeBase just remove those barriers and make everything so much easier. It it really is incredible. I I'm definitely gonna use that windshield analogy, Patrick. But it's yeah. It's it's the trophy cabinet. You're you're doing all this hard work. You wanna be able to display those trust assets that you've you've put the effort into building. So, thank you. Thank you, Patrick, Martin, and Tim. That was some really useful insights. We have a little bit of time left for some q and a. And on the screen here as well before we dive into this, you know, our, our state of GRC report and, if you ever want a demo of any of what we've been talking about or to get in touch with A-LIGN or AWS, for what they were they were referring to earlier. You'll see those details on screen. Patrick, I think this is a a question that is well suited to you. Do you think ISO 27,090 is going to be a certification as well? Is it going to displace or be wrapped under 42,001? Or is ISO making a bit of a grab and we can expect confusion that pushes some industries to get both of these as certifications. So what a good question. What a really good question because honestly, this is a point of confusion for those that that track ISO, standards. And so first of all, I have to say my response is mine, not ISOs. So those listening, please know that. But to my understanding, ISO twenty seven zero nine o o 90, which is focused on AI security, and o nine one, which is focused on AI privacy, are technical specs. They're not management system standards. And I don't think there's any vision for either of those technical specs becoming management system standards. So what I expect is that organizations that choose to employ these when they're ready, and they're very far from being ready, what I expect is that they won't be independent certifications because you don't certify a technical spec. What you do with a technical spec is use it as an opportunity to bring to bear appropriate controls in your statement of applicability. So I would fully expect these documents to have a significant impact, these specs to have a significant impact, but the impact in my mind will be through the extension of existing management system standards that are then certified. Now will it be a security thing or an AI thing? At least from my exposure to the process, we're really considering twenty seven zero ninety and o 90 one to be part of the 27 series. So these are more about security and privacy of AI versus AI specific security and privacy, if that makes sense. So those controls, in my estimation, and this is just my opinion again, will be brought to bear through the SOA, through extensions on your 27 certification, your 20 seven-one certification. Not necessarily your 40 two-one certification. But that's the beauty of management system standards. In your SOA, you can state controls that are applicable to you, bring them in, and they can be assessed as part of your management system. So short answer, twenty seven zero ninety. I don't see it being certified. I do see it being critically important, however, to the certification of either your ISMS or your AIMS. Super. Thank you, Patrick. Of course. Here's what I quite like as well. So when we talk about leadership commitment and and the objectives of an of an aims, how do you see this being practically implemented in organizations, and how do they bridge the gap between the technical and the business considerations? Oh my goodness. And I see this is from Elena Marin. Elena, thank you so much. So and this is a big deal. This really is a big deal. So every organization, as you're considering actually creating and operationalizing a management system standard, you have to think first and foremost about who you are, your organization's mission, vision, and values. And so the management body has to clearly understand what it is they're trying to create. What are we here for? What is it that we aspire to create through this organization? And then they have to understand their risk appetite, what level of risk they're willing to take on, and at what cost. So they're gonna create desirable outcomes, add an optimized risk and cost. With those things in hand, we have an opportunity to evaluate the management system standard itself in our context and bring to bear appropriate control that still serves our business while protecting internal and external stakeholders should something go wrong. So, Elena, listeners though, that's not a direct answer. It all starts with the organization's MVV and how we can employ this framework in direct alignment with the MVV. ISO has no no desire to make organizations implement controls that don't make sense for them. And so everything has to be context specific, including what it is the organization is there to create. Brilliant. Perfect answer. Thank you, Patrick. I think we've got time for one more question, and I think I'll pose this one to to all the panelists. What What do you think is the road map for enhancing oversight, and establishing clear lines of responsibility to attain accountability and compliance automation and AI systems? Short answer, racy. Good. Yeah. Make your stakeholders, assign accountabilities, responsibilities. Be sure everybody yes. Yeah. And and to add on top of that, Patrick, I think one thing that stand out is having to educate sometimes these, governing bodies internally. Right? Like many of these individuals are not aware of what these technologies are or how they need to be governed or even what, you know, ISO is, let alone, you know, what their responsibilities as governing body internally. Now we will identify and establish individuals that are aware of those things so they feel competent in what is respected of them, you know, according to these particular certifications and standards. But I think, the main thing is still taking that time as a great educator internally to say, this is what it means, this is what we need you to do, this is what we help do as a great orchestrators, as a GRC team to make sure that we're doing the things we're committing to do. And so I think the first start is, you know, really educating those folks. And here is your role. I think part of writing that AIMS is roles and responsibilities of every part of the organization to support that and then enacting that, really making that happen, not just a paper based exercise, but one that is a living functioning capability internally. And to beat a dead horse here, in order to ensure that you're using consistent language, consistent terms, consistent ideas, download and read ISO 22,989 today, please. Super. One last question which, which we'll finish on before we we wrap up is, when implementing AI systems in a regulated industry, do you think that we should implement the aims as a standalone entity, or should we aim to combine it with our existing management systems and solve that delta? So in my opinion so ISO standards, particularly management system standards, through that high level structure, when possible, or intended to be implemented in an integrated way. ISO has written a publication about how to integrate management systems. I think the thing that has to be said though is that the management system, in this case, the AI management system, has to be purpose built. That so if in this organization, the ISMS is covering one scope that's completely different than the regulated environment, In those instances, it might actually make sense to have a stand alone aims, but everything is really let me rephrase that. The scoping and context of the organization is what sets every other decision. So if scoping and context supports an independent aims, then yes, that's what makes sense. If scoping and context support an integrated aims, go that direction. Yeah. And and from our standpoint, we're seeing a lot of customers that are doing the integration. They're they're, you know, they they've obviously got other, you know, impactful certifications or or either specific to a country or a region that that they have to also comply with. So they're they're merging them and bringing them together so that they have a holistic security compliance message. And so that we're seeing a lot of that kinda audit consolidation, you know, going on across the globe. And so that's really, you know, makes the most sense, especially when you're trying to open up new, you know, new customer bases and new locations across the globe is to make sure that you're consolidating those pieces together so that it's a unified approach. And, Tim Sandage, you you bring up a really good point, and we're gonna know we're well over on time. But this is something that every listener needs to know. We're in those that have already deployed an ISMS through twenty seven zero zero one. You're familiar that with twenty seven seven zero one, your privacy controls, those are simply an extension of your ISMS. And so at assessment and certification time, they're assessed and certified as a single single system. Forty two zero zero one is its own standalone management system. And so for those of you that are planning and building begin starting to build your strategy around implementing 42,001, please know that you'll likely want to have it assessed and certified at relatively the same time, if not the same time, as your ISMS so that you're not setting yourself up for year round external audit, internal audit, just the madness that we've all been trying to get away from for years. You you gotta know that forty two zero zero one will carry its own certification date. And therefore, you'll want to plan its operationalization and its assessment and certification accordingly. Right. Scoping, planning, really, really key in this context. So great. That's fantastic session. Really, I I enjoyed this. I learned a lot as well myself. So thank you, Patrick, Matt, and Tim for for joining us today. Thank you very much to our audience as well. There are a couple of questions which we unfortunately didn't have time to get to. So please feel free to reach out to the to the contact details you see on screen, and follow-up with with any one of us. We'll be happy to help. So thank you very much all, and take care.