Navigating Software Audits: Proactive SAM Strategies for Audit Preparedness.

You that don't know metrics data 360 we are a firm that. Sorry. Software asset management services focused very heavily on license and compliance. Software license compliance and optimization. Sorry, I can't speak today. So we have all kinds of services that range from helping organizations do internal assessments of where they stand for a licensed position perspective, defending through audits, assisting with software contract negotiations and everything from there, to helping people build out and run software asset management programs for our clients. So I won't spend much time on that. But today we're going to talk about software audits and the process that you go through defending an audit. This topic can be pretty complex, although we're going to go through more of the process of how to. How to. How to defend yourself in an audit today. But I will say if you do have questions, please feel free to drop those in the chat box. I will watch that and I think there's a Q and A section in teams as well. I will watch that and try and answer your questions throughout the session today. And the one thing that I will state is I'm going to try and keep this session fairly generic today. You know, I'll use some examples from different software software publishers and things like that. But you know, each vendor is a little bit different and unique and have their own sort of spin on things. So, you know, if I say something that doesn't make sense, you know, you're thinking of context of an IBM situation and I might be talking about Microsoft. Feel free to ask questions to verify on that. Okay. Now one of the things that Haley, I believe, just dropped into the chat, feel free to go out and grab this off of that link. I think you just need to drop in your email and I'll give you a download. This is a software audit defense procedure. And so this is really a policy on how if you're getting audited, how you should prepare and how you should handle the audit. It's pretty comprehensive. It's like 20 some odd page document that goes through what we're going to go through today in a little bit more detail. And so, you know, we walk in to download that and adopt that into your policies and procedures. But I would suggest you just go grab that off of the link that Haley just put there in the. In the chat box. Okay. So I'm going to talk a little bit. I'm going to set the stage in terms of the challenges that when it comes to defending audits because most organizations, you know, want to be compliant. They are, they are doing things to Try and be compliant and then, you know, they get audited and they get these surprises. And the one thing that I will say is that, you know, it is difficult because all the major software vendors have massive portfolios of products. Like if you look at IBM, you know, they have hundreds of products, Microsoft has hundreds of products and they're all licensed differently. Right. And there's a, you know, a mix of different license metrics that, that their various products are required, you're required in order to count them. Then there's different deployment methodologies as well. Am I deploying on premises in the cloud, all of that thing? If you just look at Microsoft, for instance, if you look at Windows servers and SQL servers, although they're both licensed on a core based license model, there's differences. SQL for instance, allows you to take your servers to cloud publishers or to, you know, cloud providers. If you have software assurance, Windows doesn't. Right. So it can be very, very confusing just by looking at you know, the various, you know, within one software publisher across their different products and how they do things differently. Right. Licensing rules are complex, we all know that, but they also change frequently. Right? There's hundreds and hundreds of changes to licensing rules every year. I think there's a study done by the licensing school of the UK on Microsoft. I think they said that Microsoft, this is about two or three years ago, but Microsoft made like 300 licensing changes a year. And so it's very difficult to stay on top of that. And then as they bring out new products or versions or updates to the products that change and tweak things as well. So you might have different versions of a product in your environment that have different licensing rules and things like that. It's also hard to get accurate data on many products. Right. So everybody's got, you know, most large organizations are going to have tools that they can use to provide inventory, but the accuracy of those tools is a lot of time, quite frankly. Not, not good enough, I guess, is probably the, the harsh way to say it. You know, if you think about a Venn diagram from the perspective of is it active and do we have inventory? We should be seeing 90 to 95% overlap of those. And a lot of the times when we do what, that's what we call that a data quality assessment. That's kind of the rudimentary one. We see 60 to 65% there a lot of the times. And so people are getting data, making decisions on 60, 65% accuracy and not even knowing it. You think of all the various sources that comes through. It's easy enough to say I, I have an active directory. How many devices are active in there? And I have sccm. How many devices do we have inventory on? But not any, you know, no one company is that simple. You know, the larger you get, you're gonna have multiple domains, multiple, you know, tools that are being used. You might have multiple tools that have inventory that say different, different things, right? We have a challenge right now with one of our clients where they have inventory systems that say a server is both decommissioned and active in the same system. So which one's right? Is it decommissioned or is it active? So it's very, very challenging. The data side is very, very challenging. And then there's a constant changing of the licensing rules. I talked about the complexity, but if you look at the vendors are changing licensing rules and using that as a threat to force you to buy certain things or under the threat of being aud. If you look at Oracle with what they've done with Java, they changed from a named user and a processor model to a per employee model that is way more expensive. Broadcom, with the recent acquisition of VMware, has changed from processor to core, from perpetual licenses to subscriptions, to being able to buy single products to only bundled products. All of that's driving cost up under the threat. If you don't do it where, you know what we want you to do with these changes, we're going to audit you, right? And then you always get into areas where licensing rules say one thing, but deployment and usage is different. You know, the one that irks me the most into this category is Microsoft. If you look at their enterprise agreements, their enterprise agreements state that you have to have Office365 or N365 license for all call applied users. You know, they've got a definition of a user which is employee and contractors, which I think is vague and a challenge right there. But then you know, even if you, you know, you say, okay, well you know, we have 10,000 users, you go and you start deploying into your 365 tenant and it doesn't work on users, it works on subscriptions. So you end up having 12,000 M365 licenses because you got service accounts and other things that need subscriptions for various reasons. And so my contract says count based on employees, the tenant consumes subscriptions. And I'm over buying what my contract says. And Microsoft just goes, too bad. So there's all these sorts of things out there that make this very, very challenging. So if you're trying to be proactive about it and do self assessments internally. You have to think through these things. Now one of the questions I'm getting asked a lot, so I just thought I'd throw in a quick slide is who we actively seeing audit. Currently these are the big ones that we're seeing. Adobe, Oracle, both on their traditional products and on the Java product, Red Hat, Broadcom, IBM, Micro Focus, OpenText, Anaconda and Microsoft. We haven't seen a lot of Microsoft audits lately, but they are auditing for their service provider license agreements. So MSPs are getting audited on the SPLA side, much more so than on the traditional Microsoft side. As a note, I do think sometime in the next 12 to 24 months we will see Microsoft pick up their audit activity again. And I think it's going to be a little bit different focus than traditional Microsoft audits. Where traditional Microsoft audits were audit your on premise use. I think you're going to see them starting to audit cloud usage. So are you correctly licensing in third party aws, Google, other third party. Do you actually have enough Azure hybrid benefits to cover what you're saying you're using inside of Azure? I think that's going to be a big area of focus on for them. I also think that they're going to start Microsoft 365 audits, particularly around organizations that have mixes, say between E3s and E5s, around auditing for tenant level subscriptions or services. So I'm not going to go into a lot of detail on that, but there's certain services inside of an M365 bundle where if you turn that on every user and the tenant has access to it even if they're not using it. And I think Microsoft's gonna start looking at looking at that. So if you're getting audited or you're preparing to do a self assessment, what are the sorts of things that you need to sort of go out and either start to investigate or what do you need to know? Right. And so the first thing you need to know is your contract, you know, what program are you in, what are the legal T's and C's because they differ between contracts. Right. And they differ between how long ago you signed as well. Right. Like I've seen audits with Oracle where licenses were bought 10, 15 years ago, included things like disaster recovery licenses and then they get audited today and they have those rights that have carried through but Oracle comes in, audits them, pretends they don't exist and then they have to go and fight them. Right. The other thing to note is that a lot of the time the programs are kind of more like how you buy. They do override what you buy sometimes. But product terms, the vendors call these things differently. Microsoft calls them product terms. You hear product use rights. Oracle calls them on Oracle service terms. I think you got the online service terms from Microsoft. So those are really the real T's and C's that tell you, you know, this is how you count things. This is the standard way that things are done. You also want to understand if you have a direct versus indirect purchasing mod, and what I'm referring to here is not necessarily purchasing through a reseller, but we have a lot of clients that have systems that are managed either through outsourcers or third parties. You know, you take a hospital that maybe has a medical system that McKesson or whoever just puts it in the hospital and manages it for them, right? And you know, that's a different purchasing model and a different licensing model, but they need to still be licensed for it. Need to understand that, right? You also have to understand the license, you know, the different license types, right? So you have to understand, you have to have a little bit of knowledge on the product, how the product is used, how's it accessed, how's it deployed, what's the license metrics that are used for that. You know, is it a processor, is it a core, is it a subscription value unit, is it based on the number of gigabytes of storage that are in use? You know, there's any number of license metrics that you could, you could be used, you know, you could be, could be in use by the vendors. You also want to understand is, you know, is it a subscription versus a perpetual license? Because those might have a little bit different, you know, ramifications when it comes to an audit. Right. So, you know, if it's a subscription, when does it expire, when did we buy it? Because if they go and do past look backs and we bought a two year subscription and we had it deployed three years ago, that could be a problem if we didn't have continuous subscription coverage and things like that. So there's all kinds of things even in here that you're going to need to know and understand. You also want to know version and addition differences. Most vendors have standard Enterprise or Pro or whatever edition of the product that they use. Sometimes you're allowed to use FHIR edition. So you may be able to use this Enterprise edition to cover a standard, but in other cases you can. Microsoft again is a great one to pick on here. SQL Enterprise can cover SQL Standard Server. So if I'm short on SQL Standard but have access SQL Enterprise I can assign that. But other products like Office Pro I can't use to cover an Office standard. So they're inconsistent across the, across the product sets there you also will find differences in versions. Right. You know, again, I'll pick on Microsoft here again. SQL Server, I think it was 2012, had the rights to not license a passive side of a cluster. Didn't need anything. If I had a license, I could license the active side, not the passive side. When 2012 launched, Microsoft made passive a software assurance benefit. So if I don't have software assurance, I don't get those passive cluster rights. Now SQL 2012 is getting old, but there's still people out there that have it that are using 2012 perpetual licenses, where the active site's license, passive site's not. Once they upgrade that to say SQL 2016 or 2022 or 24, they're going to have to buy licenses because for the software assurance, which they hadn't had in the past. So you have to understand all those nuances. You also have to understand the technical sides of it because a lot of software is based on access, not use. Okay, so what does that mean? So in a user product, does the user have access to it? Right. So a lot of the times, like if you're doing like Adobe, not the subscriptions, but if you go back to the sort of older Adobe perpetual licenses, a good example is you install it on a server, who has access to it? So like, oh, you know, we only have 40 people that use it. Yeah, but who has access to it? 1,000 people. Okay, well you need a thousand licenses. That could be a problem if you don't understand that. Right, so access, who has access, Sorry. Can cause a number of challenges in these scenarios. Right. And access doesn't even necessarily mean people. In the IBM world if you're doing sub capacity licensing, so sub capacity licensing, for those of you that maybe aren't familiar with it basically says that if I've got a cluster and it's got, I don't say 20 cores in it, but I've assigned the product from, let's say cognos to only four cores. I can license just those four cores, not the full capacity. But in order to do that I have to have what IBM calls ILT installed. It has to do some reporting. Again, we won't get into that. But you know, if, if you Assign four cores and only use two and license two. Even though you can prove that it was licensed to two, IBM is going to say that you had access to four and you have to license four. You know, so ILMT doesn't say how many you actually used. But if you have other tools that can monitor it and say we only ever use two and we have the equivalent of two cores of licenses now, they have a conversion on these PPU things, but I won't get into that. You know, that can cause a problem. So it's all about access, right? So understanding the technical access of the product is important. Also, understanding external access and what that has from a ramification, from a licensing perspective. So do you have contractors, third party, do you have consultants, those sorts of things that are accessing these systems and licenses? And what does that mean? Right? You also have to understand deployments as they relate to the contract, product terms and things like that. And so here, this is what, you know, good example is this. We already talked about tenant level. Sorry, excuse me, Tenant level services being turned on in Office365. That's an example of deployments and what the terms are in there. This could also, you know, be how you deploy. I'll go back to another Microsoft example here. SQL Server. If you have services within SQL servers, like analytics services or integration services, if it's deployed on the same server as the database, it's not licensable. If you separate it onto a separate server, it becomes licensable. You have to understand all of these. You have to understand the attributes of the deployments, right? So this sort of goes to the license metric. How do you count things? So what is a core? How does that vendor define a core? Right? Because Microsoft defines a core one way, IBM defines a core another way. AWS defines a core another way. So an example here is, if you're running certain products on AWS of IBM, IBM defines a core certain way. AWS defines a core another way. Which one are you contractually obligated to purchase under? Because if you, if you look at how IBM defines cores, it's based on physical cores in a server, AWS will define those as threads, and they'll have more threads than actual physical cores in the server. So, you know, you have to understand all of this stuff. And this is, these are areas that people get caught in audits. And the publisher know this, right? And then what's the process? Right? So if I'm getting an audit, what is the process? Do I have to go through an audit? Can I do I have the ability and capability to do a self audit even if I'm getting audited. Can I do a self audit before the audit happens to figure out where I sit? You have to understand the validity of the data from tools. We got clients that have SCCM deployments that when you look at them, they're actually reporting more cores in a processor than the processor actually has. Normalization even of the data from the tools, not even talking software titles becomes important. You have to understand how to challenge an audit report. I'll get into that more, more in a little bit here. And then the, the other part of this as well is, you know, an audit. I always say that an audit starts as science. Right? So when I get into an audit, it starts as a science. It's, it's all what we're talking about. What, how many licenses do I have, how do I count my deployments, how do I assign my licenses to those deployments? So very scientific. You know, what's my contract state, all that sort of stuff. And then a license position gets created and you look at it like this isn't right. And then it goes and shows a bunch of shortfalls and it goes to the publisher. And then at that point in time, it becomes a negotiation. It's no longer science becomes a negotiation. So I have to understand how to negotiate an audit. How do I negotiate a settlement of an audit? I'll get into that in a little bit more as well here in a little bit. Now, if you've attended my other webinars, I have a whole webinar where I just talk about this slide for an hour. But this is sort of the process of doing software asset management and audit defense is kind of encapsulated in all of this. Right. So what we just talked through in these last slides, we talked from the right to the left of this. But I'll just go through this real quick. Right. I have to be able to collect inventory. I need to know that that inventory has a high level of data quality, 90 to 95%. And the reason for the importance of that. So go back to our simple example of Venn diagram. I have something in a directory that says it's active, I have inventory on it, it's 95% active and inventory. Right. The reason that that is important is because if you can't get to 95% data accuracy in an audit, they're going to make assumptions. And those assumptions typically cost organizations substantially. Right. And I'll go back to Microsoft here. If you have 65% data and you have 1,000 servers and 100 SQL servers, they're going to assume that if you only have 65% data, they're going to just extrapolate out that you need another 35. So you have 650 inventoried servers, which say 65 SQL. They're going to say you have 35 other SQL servers and then just call them all enterprise. Right. But you're going to have a mix of express, standard, enterprise, and that's free to a few thousand bucks, a quarter to tens of thousands of dollars a core in licensing costs. And they're just going to assume they're all enterprise. That's an assumption you do not want to have happen, especially if, you know, like we do that. A lot of the times, database challenges in a SQL audit tend to be express. There are, there are instances of standard enterprise, but a lot of it tends to disproportionately be expressed. That's not reporting additions or not reporting or whatnot. Right. And that's the free version. So you have to have that data quality. And then you need to be able to normalize that into licensable titles. They have to take your software licenses that you own out of your entitlements, get those to the license metrics that you're measuring, have your data in that, and then build a license position. And you need to be able to do that in an optimized manner. There's a lot of audits that we see where an auditor will say, hey, you're $3 million offside, and we can go and take the same data that they use, same deployment data, same license counts, not do anything. So now you're only a million bucks offside as because of the way that licenses get assigned. Right. Did they assign them in the most optimal manner how you bought them? By the way, if you tell an auditor how you bought them and how you assign them, it's probably not the most efficient way to be using your licenses. But you need to understand how to do that. Right. And then you need to understand how to then go and negotiate all this. So this here methodology that we talk about all the time and the process that we take our clients through with this is very, very relevant in how you actually defend, defend yourself in an audit. Now. So I talked a little bit about, you know, kind of what you need to know in an audit. The biggest areas that we see is these haven't changed in quite some time is access to applications installed on servers that pose those access issues. Proof of roles, I say server roles here Production, non production clusters, those sorts of things, that's a problem. But we're also seeing more and more where proof of roles in terms of employee type and things like that becomes a problem. Directories aren't clean. So we'll see directories where you could make an assumption that there's 5,000 more devices on the network than there really are. Now you might say 5,000 of 100,000. Maybe that's not a big deal. But when I'm saying 5,000 I'm talking like 30, 20, 30% more in a 5, 8,000 seat organization. Active Directory is never clean in terms of users and devices. In fact, when I tell people most of the time we, the first thing an auditor is going to do is come in and request you to run scripts against Active Directory to show them the devices and users in there. They basically are like, oh no, we've got a problem. Right? And yeah, it can be a problem. There's methodologies you use to make sure that your accurate counts and things like that. But that takes time. There's definitely, I could probably spend a whole session just on that to be honest. A lot of the times people say oh, we're okay, we've got SAM2, we got Snow or Flexera, our ServiceNow, SAM Pro. But you know, then they find out not everything's in them, it's missing domains, there's access issues, all of that. A lot of the times it's just incorrect understanding of how to count things. You know, I, IBM ILMT is a big one. I don't know how many times we get called where clients like I'm getting audited by IBM, I'm doing sub capacity. They tell me I need ilmt, I had no clue I needed it. Right? So you know, that's causing the problems because they're just like, well we just assigned two cores and we're great. And they're like no, it's full capacity. Right? So, and then I think, like I said, I talked a little bit about some of the stuff that I think is coming to the cloud here. A lot of the times audits are caused or the challenges in audits are caused by humans. Quite honestly, you know, people on your team that are well meaning but you know, an auditor will ask questions or even a software rep or a technical person will ask questions and they'll just throw things out like, hey, any application on a server is licensed via Citrix and as soon as a vendor hears that they're like, ah, they're probably doing oh, I'm drawing a Blank on the term. Can't believe that we license only the number of users that are active at any given time. Not all people that have access. Right. And so you say that to a vendor and if you're not careful, they will make assumptions on what you mean by that. Right. You know, we'll see. A lot of the times people say things like, but my vendor and account rep told me that I could do this, or my reseller rep said I could do this. And it's not in writing, it's not in the contract. So you have to be very careful in terms of what you communicate. We saw recently an organization where they were talking with somebody on an account team in a strategy session, talking about something that they were planning and throw out some numbers of where they think they might be from a licensing perspective, if those plans go according to plan, that person went back and told the account team that they were using that many licenses and they, they were under the threat of an audit and they weren't using it. They were like, it was something like, you know, they were using 500 and they might be potentially growing to say 5,000. They went back, told them they were using 5,000, then all of a sudden the audit threats come and it was six months of, you know, you're not actually showing us the data. We don't believe you. We know because so. And so was in the room when he said it was 5,000. You just have to be very careful what you're communicating with them. Right. And the last, I think this is the last piece before I sort of get into the process at all is a lot of the times people say, like, I have a SAM tool. The auditor's going to accept the data. Yeah. Maybe they're going to validate it though. Right. So you may have Flexera installed in an IBM audit and IBM says they'll use Flexera for Iot. They're still going to validate it to make sure it's reporting correctly. All those data quality issues, you know, flow down into, into the SAM tools. And so they will, they will definitely check it. Right. The other thing is a lot of the times the SAM tools themselves, they can't do complex license. Still to this day, you probably, I don't know of a SAM tool that would make a great Windows or SQL Server license position. Right. You know, but they'll tell you they can. They'll show you things that make you think that they can. Chances are you either under licensed or over licensed if you're, if you're, if you're if you're relying on that and then, you know, they often start with ad and the SAM tools don't do much with ad, right. So when you go in and do a SAM tool, it's just looking to see do we have devices and do we have inventory. It's not doing that sort of data quality check. Right. So, you know, they don't necessarily start there either. So we've kind of gone through what you need, what you need to know. Now I'm going to get into an audit process, right? So this is the process of audit. There's a selection, you know, this is how, you know, selection is I got selected for an audit. So let's talk about how not to get selected for an audit. We're going to talk about that. There's notification, right? So you basically received a letter to get you that you're going to get audited. We might want to try and negotiate that. We'll talk about that. But you know, that is your time to get prepared. It's not, I got a letter, let's not do anything. If you get a letter, kick off your team and get started. There's the scoping. So once we, you know, have gotten through, yes, we're getting audit, there's a scoping and kickoff that happens. And that's, you know, kind of what's in and out. That's the scope of an audit. Is it our entire enterprises and all products in the, you know, if it's all, if it's IBM, is it all products? Is it one passport agreement? What is the scope of it? And that's also the timelines, you know, what are the time frames to get the audit done. Then you're going to start data collection. You know, that's how and what to collect and share. That's going to be deployment information, it could be licensing information. It's going to be information that maybe isn't even relevant to the vendor that you need to be careful of. Once the data collection is done, it typically goes over to the auditors to do data analysis. So they'll create these license positions. You'll hear elp, the term elp, effective license position, estimated license position. The E gets exchanged there. But that's kind of the what you have deployed, how many own and any overages and underages. And a big thing here is how not to waste time, right? Because if you send them bad data, you're going to waste time. So we'll talk about that. And then you're going to get into the accuracy of your data and the review. So once I get that E LP back, is it correct? Are there errors in it? Are there assumptions in it? How do we review it? How do we push that back? And then once we've come to where we can with the auditors, there's a handoff from an auditor to the software vendor. And that's sort of what we agreed to with the auditor and then we get into a negotiation. Now, not all vendors use third party auditors. Some of them do them themselves. A lot of them you'll use third party auditors. So you just kind of adjust this a little bit. If it's like Oracle and the LMS group is doing it themselves. But you can kind of consider LMS to be handing off to the sales Org. Right? Okay, so let's talk about selection. Because people are always like, how do I get select it? Right. The big things are kind of the things that you would would think of merger and acquisition. Usually if you did an M and A, expect to get one or two audit letters dropped to you within the first 12 to 18 months. M& A is something that these guys look for and once it happens, they, they pounce on it. Right. If you had a change in spend, particularly if it went way down, that's a problem in their eyes. And if they don't understand it, they'll drop an audit on you. If they're having conversations with you and you have a complex organization structure and it seems like you don't have a handle and a good view on things, probably a good time for them to audit you. Complexity of your licensing agreements. Microsoft, for example, when you start mixing E3s and E5s, I think that that's going to be a problem. Right. Like where I talked about decrease in spend and then we talked about information gathered by various sales team members. You have to be very careful in what you're telling them, making sure that they understand it. So those are the things that trigger them. How can you avoid it? Is, you know, maintain a good relationship with them, be open with them with lots of communication. If you're change, if your spend is changing, make sure that they understand why. You know, hey guys, unfortunately we got to another product. Hey guys. We had, you know, a significant downturn. We've decided not to use maintenance. We're going to run unsupported. We know that's a problem. Here's how we're managing it, right. The other thing that you could potentially do is negotiate the audit clause in your contract with your signing them. So instead of them being able to audit, you force them to do a self assessment first. So self assessment would be where you run an audit internally. You hand the data over to them, they review it and say, yep, this is good enough, we'll accept it or nope, we don't agree with this, then we'll do an audit. A lot of times you can head off an audit with a self assessment and it's a lot easier because you don't get involved with the auditors that are going to make these assumptions. Right, because an auditor is. The thing to note about an auditor is they're going to assume you guilty until proven innocent. And if you give them data where you know something is missing, they're going to assume the worst. Right. So for instance, you may have an Excel spreadsheet that tracks all your versions of SQL Server. And you know, so you know that's a standard, that's an enterprise, that's express or whatever. And you hand that over to the auditors and they're like, that's not automated, that's just a spreadsheet. How do we know that's real? We can't validate that. Too bad. Everything's enterprise if your discovery tools didn't tell us otherwise. Right. So you have to, you want to watch that, right? So you need to make sure that you understand the licensing models and that you can manage them, that you have a way to track it and that you can communicate that to them. And then, you know, I suggest understand the big risk factors and show the soft vendors you have processes to control them. Right. So if we know they know using Citrix and you know, we're, here's how we're controlling access to our users. Right. So make sure that you understand what those risk factors are and you know how to communicate those back. But that takes a lot like talk a lot to your vendor. So the next thing is the notification. Typically what will happen is you'll get a formal audit request. Usually it's in the form of an email. Email or a letter. It's very legal sounding. You know, sometimes you might get a SAM review that's different than an audit. Usually the differences is more in the way that things get settled in an audit. Typically there's penalties, they can charge you above list and things like that depending on the vendor. With a SAM review, if you're found to be non compliant, it's usually just buy under the terms of your current contract. It's not as rigorous as well they're going to come in and specify the audit partner and the time Frames that could be negotiable. So we've had, you know, companies come in and, you know, auditors come say, hey, we're going to use kpmg. And for various reasons, client doesn't want to use kpmg. They're like, nope, we need to use somebody else. Or, you know, we're using this small audit partner of ours. Nope, we want one of the recognized national firms and definitely the timeframes. Then they're going to want to set up the meeting, you know, with the auditor, between the auditor, the vendor and the customer. Okay? So you have a kickoff meeting. Typically, what will happen is it'll be the publisher, the IBM, the vendor, say, Deloitte, and then you as a customer. And then once that kickoff meeting happens and you start to get into data collection, the vendor disappears. You work with the publisher until the handoff goes back. Right? So a couple of things to note at this stage. If you get the notification right away, kick up a project team to manage the audit. That should include the technical people. You should have a single point of contact. That's the only person the auditor and the vendor can communicate with throughout this process. And we'll talk about why in a little bit. That might include legal, it could include finance, could include purchasing. You know, all the main stakeholders, Right? You need to take ownership of the timeline. Because a lot of the times I've seen them come in and the auditor, they're like, oh, we'll be done this thing in eight weeks. I'm like, yep, two years later, it's still going on, right? So, you know, the complexity of environment, you know, what you have going on, you know, you want to make sure you control those and I would say potentially delay if you need some time to understand your data. Right? You can't get rid of these things. But a lot of the times we'll delay a little bit, you know, ask for an NDA, those sorts of things. So you can start going and doing the internal software assessment to look at your data to see if there's any areas of problems or any areas where you're not gonna have certain things that you're either gonna go find out or you wanna have stories around so that when the auditor gets it, they understand. They understand your data. They're not making those assumptions. Okay, let's say you say, don't hide the data. Don't go on starting uninstalling, doing things that are against your contract. You just wanna get a handle on it. Okay? So at this point in time, it's like do we know all the products? Do we have the licenses? Do we have 95% accuracy? Is our knowledge based on data or is it based on. We think, if it's based on, we think that's a problem. And I, you know, I see that quite a bit actually. We think, yeah. Okay, so, you know, here's a pre audit checklist. You know, make sure you set up your audit team. Make sure you have up to date entitlements and contract stacks to start pulling that stuff, talking to your resellers, all that stuff. Put an NDA in place with the auditors, understand the scope, and you'll want to understand the scope from your side so that maybe you can negotiate that. You know, we have one audit that's going on right now where they centrally personalize some stuff, but they have affiliates that purchase others. And we've been able to say, you know, get the audit to just essentially personalize them in the central data center. Right. So, you know, you might want to control the scope. And then I would suggest, you know, build your own or have experts like ourselves build a nice estimated license position prior to the auditors doing it so that you can see what sort of things you're going to need to be concerned with and make sure that you understand. Okay, so what happens next is there's a scoping and kickoff. This is where you talk about the data that's going to be required, how to collect that data. You know, what, what, like I said, what's included, what's excluded. Right. And here, you know, make sure you have the NDA in place. Request clarification on data requirements before committing. Right. So if you don't know why they're asking for something, make sure you ask, why are you asking for this? What do you need for? They'll ask for a lot of stuff they don't need. Right. And so you want to make sure you understand it and then you also understand how they want. While that's in the next, in the next step here. But at this point you want to take ownership of the project timelines. Don't just agree to what they say. Okay, next step is data collection. It's usually done remote. So you collect the data and then you'll send it over to the vendors if they. Sometimes they'll request an on site data collection verification, you know, where they'll come on site and ask you to pull up servers and show them certain things or whatnot that can happen. They're going to interview you. So they're going to want to understand what Your IT and procurement policies and practices are, you know, they're going to talk you through data collection, conversations, observations. They'll give you a, I call a self declaration. They're going to give you a template of how they want to see the data. And if you fill that out, you can provide that back to them from your inventory tools. They're going to run across records on the data for the tools you've already have. So like they said, if you got SAM tools or sccm, you can pull data from that. They're going to talk to you about running scripts for various apps. So a lot of the times inventory tools can't actually give you what you need. You might actually have to run scripts and things like that to understand what's installed and what's in use. And so they'll let you know how to, how to do that and then you'll need to execute those scripts. Now, a lot of times organizations push back about running scripts. They'll want to try and use their own stuff, and I suggest you do as well. But there's certain things, like I said, that you just can't get out of the tools that you will have to run these scripts. What you want to do at this point in time is make sure that all data requests are reviewed through your spoc. Data request from the auditor goes to the SPOC and the Spock goes internally and gets that data, comes back to the Spark, that gets reviewed by the team and then pushed to the vendor. You know, so make sure all of those communications goes directly through that single point of contact. Because you don't want them running around collecting various things that you don't know or somebody just sending them something that inadvertently could cause some problems. Right. I've seen it many times. Oh, I just sent them this because they asked for it. It was like, okay. But that's, you know, it doesn't have version, doesn't have additions. It's got, you know, decommissioned servers and, you know, whatever it is. Right. So you want to limit the scope of the scripts if you can, you know, make sure that the data release the auditor, when you send data is good quality. Right. You do not have conflicts amongst the data you're providing. And then make sure you understand why the auditor needs the data. And I've had them where they said, just run this and then they're collecting other software publishers out of scope, not even part of that vendor. No, we're not sending you that. Right. So just make sure you, you're comfortable with what you're sending Them and that you understand it. And then from there, once they have all that data and that process could take weeks, months, years sometimes. What will the auditors do? They're going to consolidate that and generate these worksheets. And so these worksheets are licensed positions. You'll see multiple tabs per product that talks about how things are being, you know, what's deployed, where does it sit, what's the license metric, how is it being licensed? And so they'll also ask for additional data or follow up. Right. So you know, if you don't have versions or additions or you send them just a spreadsheet, they may want to see screenshots like, you know, this is where they're going to follow it, validate the data that you provided them. And so again, just use that consistent review and communication process through your, your, your Spock. I'd create your own license position so that with, when they, with the data that you sent them so that when they come back, you can compare how yours is created versus theirs. And then you want to start preparing your defense on where you, the auditor will use assumptions. Okay. Yeah, Ben, do a question. Mute you or not Maybe just type it in. Yeah, can you hear me? The question is, should you be doing that license position before you send the data to the auditor? I would, I would do one before you even start sending data so that when you're looking at it, you can kind of get an idea of if there's any issues in the data. And then I would be taking whatever data you sent to the auditor and doing another position. And the reason for doing two is usually there's a lag. Like you, they won't, they want the data to be current. So if you run a run data and then like eight, nine weeks go by and then you start giving them data, you'll want to run it on that, that data because as we know, these environments change all the time. Okay, so then what'll happen is once that's done, they're going to create, they're going to send you back this license position. Okay. And they're going to seek your confirmation and agreement on it and they're going to provide you with not enough time to review it. A small customer could have hundreds of thousands of rows of data. You think about user based licenses, all employees, every product in a single tab, there's hundreds of thousands of rows, tens of thousands. Even in the smallest ones, we've seen audits of over a million rows of data that need to be reviewed. Right. And so what you should be doing is the first thing I do is when I see an ELP is I go and look because the main, the main tab in them usually is what they call the elp and that's gonna have the product, that's gonna have your deployed counts and your licenses and your deltas or overages. So the first thing I do is I go and look anywhere where there's a shortfall if we're over licensed, according to the auditor, I'm probably not even gonna be concerned with it. Now there may be times where if I can, you know, shuffle licenses around between products and things like that, I'll go look at that. But the first thing I do is go and look at anything where there's a shortfall and see what's done. I'm going to look at how they assign the licenses. I'm going to look and see if they use the license metric. I'm going to look and see if there's anything that we have in our ELP that's different than theirs. I'm going to ask them to provide any assumptions that they've made in order to come up with that position. Right? I'm going to seek clarification of anything I do not fully understand from them and then I'm going to provide agreement with conditions. Right? So in other words, what ends up happening with the auditors is because they will not make a call on behalf of the vendor and they will not. So let's say, let's say it's SQL Server, we don't have the additions, so they've made some assumptions on everything SQL Enterprise. Then I go to them and say, hold on, not everything's enterprise. You know, 40% of our express, 40% standard, 20% is enterprise. So the shortfall should be 40, 40, 20. And then they'll come back and say, okay, well we'll agree to an extrapolation like that potentially, but we're not going to include the free ones. You're like, well, that doesn't make any sense. So I will agree with you. Doing an extrapolation. I will agree with you. I get that you can't make that call, but I'm going to agree. But I get to provide comments to Microsoft before that gets handed off that I do not agree with this and here's the reason why, right? So you want to make sure you provide, you know, if you agree with something that's still, still not in a good position for you, that you, you hate, say why? Okay, so here, here's what I always tell People, I'm going to use 9 million because it just divides easily into thirds. Okay, it could be 900,000, could be 90, but let's use 9 million. Auditor comes back and shows a $9 million shortfall. Here's what's going to happen. Typically, 3 million of it is just absolutely incorrect. It's based on bad assumptions, maybe even more. It could be 3 to 5 million of it is based on bad assumptions. A third of it is what I'll say is gray area stuff. Right? So licensing rules aren't clear on this. We have an old contract that states that we can do QA environments or disaster recovery for free. They're putting licenses on it because they don't know whether that's true or not. They sort of see it, but don't necessarily agree with it. You know, it's things like that. And then the last third is typically, yeah, we had some growth and that was true up. Now the thing is, what you want to make sure is that anything that is a normal true up, if you have a contract where you can true up annually is not called audit findings. It's not called shortfalls. It pulled out and it's like, no, that's just our true up. We grew up our server footprints or whatever it is by this, this year. And that was going to be our true up because those are not findings. And the reason that becomes important is because if you look at the clauses, they typically say if you're Non compliant by 10% or more, you pay for the audit, we can charge you penalties, blah, blah, blah. Right. So this is where what we want to do is we want to get rid of everything that should not be in there. Just the wrong stuff. You're not going to allow this to be handed off to a vendor until all the stuff that is wrong is pulled out. Okay. And then what you're gonna, what you're gonna be left with is this gray area stuff and the true up. And we're gonna take the true up piece. We're gonna say that, that that's not non compliance, that's true up. You, you know, you agree to that, Mr. Auditor? Mrs. Auditor? Yes, we do. Okay. So we're gonna have, I'm gonna draft a letter that goes to Microsoft with this and we're gonna call that true up. And you're in alignment agreement with that. And I want you to note that in your elbow. And then you get them to note that in your elp. And then what's left is the gray areas. This is the stuff that you're gonna, this is where it changes from the art to the negotiation. That's the stuff that you're gonna go negotiate with the vendor. Right. And the other reason we want to do this is because if you go to them with that 9 million and then you're like oh hey, 3 million was just wrong and it's handed off to the vendor, guess what they do. We already made concessions to allow you to take that 3 million out. Well, the 3 million was just wrong. Well yeah, but it was concession because the auditor handed off the final report and it was included in it. We don't want that. We need concessions beyond the stuff that we don't agree with the auditor on, that we think we're right and they're wrong. Right. And so we don't want that. And we don't want that true up in there either because it's like, oh, the true up that's, you know, so that you have to be, you have to understand that stuff. And that's why we want to make sure that that's documented very well. And so then the next piece is it gets handed off to the vendor. Right. And so what will the auditors do? The auditors will do a close out. So they're going to basically present it as fact findings to the software publisher. And then this is where we, this will be where if it was done by an auditor, this will be where Microsoft, IBM, whoever comes back in the room and it's like here are the findings. Now they should know nothing to this point. They should have no clue whether we're over licensed, under licensed anything. This should be the first time they're, they're getting this. So do not expect any concessions out of this meeting or anything. It should be the first time that they're hearing about this. Okay. And so what will happen is the auditors will position the ELP and we will clarify all of the areas that we did in the last step which we don't agree with the elp. And then we'll say to Microsoft or IBM or whoever, these are the things that we need to negotiate on. We want to have a conversation with you. And they'll say, okay, I need to digest this. They're going to go back and then we'll get together with them and then it starts into the art of a negotiation at that point in time. Okay? So you know, the main thing here is to make sure you highlight any disagreement on any compliance observations. You do not commit to any settlement timeframe, don't care if it's May and it's IBM's year end or December I guess is theirs. Oracle's May don't care. Right. We're not settle, we're not just going to settle this to settle it because you have some arbitrary date in stone with, you know, unless we are in alignment to what this is going to be doing. And then you're going to start to prepare for the negotiation. Okay. And then you're going to go into the negotiation. And what I would say is when you're mitigating an audit, the one thing to note is that an audit finding, like if they find you're non compliant, you're going to try like let's say, yep, I was just non compliant. We, we were doing something. We didn't understand the licensing rules, we were non compliant, we owe a million dollars. But you know, we, we were trying to be to the intent of the contract, we weren't doing it. You're going to try and negotiate with them, Right. So I would say anything that's gray shouldn't be in there, you know, a little bit more aggressive on like not paying that type thing. But in here what you want to be doing is you want to be thinking about what'll happen. So the vendor will get you initial quote with some very high figures. You know, a lot of times that list not at, you know, showing penalties, not at your contractor price, whatever that is. They might offer some concessions or a little bit of discount based on some of those things that you set in there. And there will be a lot of the times they'll, you know, want you to purchase and, and maybe sometimes they'll get you to do a commitment to something else. Right. So do a big purchase. We'll let you off the hook of 20% of this, but you're going to buy some cloud or something else. The real thing you want to be balancing here is they're going to try and balance the immediate revenue against the future revenue and the time of the payment and the relationship. These are the things that they're going to try and balance, right. So if it's close to your end, they want the time of the payment to be close to your end, which at this point in time may become into your favor. They might try and balance off some immediate revenue for future revenue and they're definitely going to be looking at the relationship. So you want to balance these things in that sort of negotiation and things like that. Okay. So again, you want to make sure that you have strong arguments in order to shade a good deal. So if you're going to try and say, like, look, it's showing 4 million. We think it's a million. You're going to have to have strong arguments backed with facts. And then you know you're going to request concessions on the gray areas. Right. If it's filled with assumptions or whatnot. And then at this point in time, you're probably going to want to use time to your advantage, not to theirs. This is the process of handling an audit. We talked through. Scrolling is not great here today. If you look at the process of handling audit, there's the selection process. We talked about what types of things you can do to avoid getting audited. There's a notification what you should do to get prepared. Scoping what's in, what's out. Data collection. How are you going to collect it? Are you using scripts? How's that data flowing through your single point of contract? Contact, sorry, you have data analysis. The vendor is going to. That's where the auditor goes, does their things. The how not to waste your time is to make sure that the data quality is good. Anything where the data quality is not good, that you've provided them with backup information as much as you can in order for them not to make bad assumptions. You're going to review their elp, focusing primarily and only on the shortfalls. We're not going to waste our time on anything that's over unless it can become to our advantage. Because they're not going to go and say, hey, you owe 4 million, but you overpaid by 4 million here, by the way. That could be something using a negotiation. I didn't talk about that, but a lot of the times we just want to see get that delta to be as small as possible, knowing that probably 67, 60 to 70% of it is junk and 30% probably a true up anyways or growth if it's a product that we're growing on. And then you know, it's going to get handed off to the vendor. We're going to make sure everything is documented that we don't agree to. And then we're going to negotiate a settlement. And that is the process of defending an audit. Hayley, do you want to just drop in the chat one more time? I highly suggest you go grab this and, you know, drop this in your policies and procedures, because we go through and talk quite a bit about this in a little bit more depth of what you should do. At each step in here, you'll see everything around the kickoff meeting, what to pay attention to. And so this is good to get in your policies, you know, binder or whatever, so that if you do get audited, it's, it's there and you can you have that available. So don't think I saw any other questions come through. I'll give a couple seconds here. If anybody does have a question, feel free to drop it in the chat or raise your hand and if there's no other questions. Okay. Awesome. Well, thank you for attending, everybody. I hope this was helpful. If you have any questions, feel free to reach out. Miketrixdata360.com Happy to answer any any questions you may have. Have a wonderful day, everyone. Thank you.