The Software Audit Survival Session

Good afternoon or good morning, I guess, depending whereabouts you are. Welcome to our session on software audits. In this session, Chris and myself are going to answer any questions that you have. So when we, when people signed up, we got a number of questions that were submitted. So we'll go through those and try and answer as many of those as possible today. But if you have a question, there is a raise your hand feature within Zoom. I think it's. If you click on the control panel and then I can't remember if it's under annotate, maybe if somebody on the team can figure out where that is. There's a raise your hand feature. If you raise your hand. We'll happily take your question when we get to that section of the, I guess production today, if you will. So we're going to go through those, we're going to talk a little bit about how audits work and the top challenges of dealing with those. And then we're really going to spend a lot of time on Q and A. Like I said, we had a lot of questions submitted. So we can go through those questions. Or if you have a question, you can either put up your hand and we'll bring you on and we can chat about whatever your specific question is, or we can also just. You can also drop your question into the chat. So Jordan just said under reactions and then you hit raise hand. I just wanted to kind of set the stage. Like when we were. All the registrations we had, I think there were like about 50 or so that came through. These were sort of the top, top way that questions came in. So if you look at it, a quarter of people are really interested in audit process and we are going to touch on that today. Quite a few people want to understand things around legal rights. So how can you push off audits? How do you, how do you do a settlement? A lot of people want to understand how to prepare for an audit. And then there were questions around, you know, the vendors who are auditing, what tools you need in order to do an audit. And there were a lot of Oracle specific questions, which is no surprise because Oracle is one of those vendors that is auditing quite frequently right now. But basically what we want to do is kind of talk a little bit about at the high level of what the software audit process is. And so this really is, regardless of vendor, the way that a software audit works sort of goes through each of these steps. So there's a selection process, we talk about that and how not to get audited. But really at the Vendor themselves, they have criteria in terms of what gets you selected to be audited, and sometimes that could be nomination from account teams, although a lot of the times the account teams will tell you that they don't do that, but that's not always true. We'll go into the reasons why those happen, but once you get selected, you're going to get a notification. And we said that that notification period, when you get that, is time to get prepared. And again, I'm going to go into that in a little bit more detail. But really, we believe fundamentally that if you get audited by a vendor, you should run an internal audit yourself prior to the auditors coming in so that you can kind of see what's going on in the environment. And I'll explain that in more detail a little later. And then once you get the notification, there's a scoping and kickoff call and it's important there. Again, we'll talk in details on this, but in that it's important to nominate a single point of contact that the auditor is only allowed to talk with that person. Make sure that it's defined what's in the audit and what's out of the audit. That could be products. So if you look at the big vendors like IBM or Oracle, it could be, is ERP in? Is it out? Is it just database and applications on the Oracle side? That also could be what parts of your organization are included in the audit? And so understanding and narrowing the scope is important. And then you're going to go into a data collection phase. And so that's, you know, how do they collect what's installed out there? How do you get the entitlements or what you're entitled to? We talk a lot about what to collect and how and what to share. You know, an example here is, do you allow the auditors to run their own scripts or do you use, you know, your own existing tools to do that? And what's the benefits and disadvantages of those? And then, you know, if, if they're asking for certain things in a certain way, are you sharing more information than you should? You know, we've seen vendors in the past where they run scripts that collect publishers outside of their own. So they're kind of using it to collect, you know, competitive information if you're, if you're not careful what you give them. And then once that data is collected, you go into this data analysis and validation phase. And so that's really usually the auditors themselves. So they're going to take all the information that was collected and then they're going to come back to you with these things called estimated license positions. They're going to have a lot of questions throughout that data analysis and validation phase if they're doing their job correctly. So we talk about how not to waste time in that phase and then you're going to get into the accuracy of the data review. So in other words, when they come back with a licensed position, how accurate is that? How do you push back on that? How do you get assumptions out of there when they make assumptions? And then depending on the vendor, not all vendors perform the audits themselves. So Oracle, for instance, they have a group called LMS that performs audits. Microsoft uses third party. So you know, if you've got, sometimes this phase doesn't happen where you're handing off from an auditor to the software vendor because the auditor could be the vendor itself. But, but there, there's still a similarity sometimes in that you're handing, handing off. If they're doing the audit themselves, you could be handing off from the audit team, the team that's doing the audit, to the sales team where that settlement gets discussed and negotiated. Okay. And so when I talk about audits, I talk about science and art. And the science is probably pretty much everything up until those last two to bubbles, if you will, of how do we actually go out and count and know what's installed out there and things like that. And then the art piece turns into the negotiation because every audit turns into a negotiation and that's the art of the negotiation. So what are the challenges for organizations? Right, so the challenges are that, you know, all major software vendors have massive portfolios of products and so they're all licensed differently, they use different metrics. So even if we just talk about IBM, you know, you've got numerous different products, they all count them different ways. And so it's hard to set a process internally just to, just to look at that stuff. It's also hard to get accurate data on many products. Right. So you know, a good example or a simple example here is additions of SQL servers. The inventory tools quite often don't report whether it's express, standard or enterprise. You know, the difference between free and, you know, 30, 40,000 bucks for a couple of, of core licenses. And so if you give data over to an auditor that's missing things, they're going to make assumptions. In this case, an auditor will assume a SQL without an addition is actually SQL Enterprise. And that, that can be punitive. There's also no built in license controls. I mean, most software is a honor based system, right? It's not. You don't purchase 100 licenses and when you deploy 101, you can't, you know, you can't deploy that until you go get more licenses. You just keep deploying things. And then, you know, obviously there's complex licensing rules, right. And then there's always changes those licensing rules to compound that. Right. We were just having a conversation internally today about if I have a SQL 2008 license, a perpetual license, or 2008 R2 perpetual license that had UMLAN of virtualization, how can a client take advantage of that if you know this is a unique scenario, but when the rules today are different, Right. So you have to understand how those licensing rules have changed, which ones apply to you and all of that. Okay, so again, one of the things that we got asked on the, on, you know, one of the main questions we got asked was what triggers audits? There's quite a number of things. Mergers and acquisition activity is a big one. So if you're doing M and A, that's usually a trigger for an audit. One of the big ones that we're seeing right now are vendors that are changing licensing metrics. So Veritas is a good example here where they're moving from perpetual licenses and moving things to like terabyte based licensing and, or you know, subscription and cloud based licensing. Citrix is another one in this category where they're trying to get away from their perpetual licenses and move to cloud and they're using licensing audits to sort of drive those changes, particularly in customers that are pushing back and not wanting to change metrics. We see audits in customers where they rely too much on their SAM tools and the vendors know that those SAM tools don't have everything in them or they can't report on certain things. We've seen them be triggered because you have a conversation with your account rep where you've got a misunderstanding of how licensing works and they realize that you're counting incorrectly and that'll drive it. We've seen them be triggered because of large workloads being moved into the cloud. Some software publishers allow you to use their licenses in the cloud, like whether it's aws, Azure, Google or anybody else and others don't. And vendors that don't allow you to move them into the cloud without purchasing different license types will trigger an audit if they know that you're moving, you know, large workloads over into AWS or whatnot. Another big trigger is if you basically tell that tell that vendor that you're moving away from them. Right. That will trigger, trigger an audit. So you know, these are just a few of the things but you know, these are the sorts of things that drive, that definitely drive those audits. I'm going to skip this one because there is a bunch of human error that happens. But we'll probably talk about these as we go through, through the questions and answers. So like I said, I just wanted to set the fate, set the stage with the process because this is the, this is the key thing, doesn't matter which vendor you deal with, this process is what is going to happen or some variation of it. Right. And so the key thing really is to sort of take a look at that process, understand that process, understand what to do at each, each phase of that process, and drive through there. So today we got Ben, Chris and myself on to answer, answer questions. So like I said, we'll be, we'll be going through questions that were submitted upon registration or feel free to ask your question either through the chat or raise your hand and we'll, we'll go from there. So I think really, Chris, maybe what we can do is I'll just maybe pull up a question and let's, maybe you can kind of give some thoughts and I will feed into that as well. So one of the questions that we got asked, and I think this is an interesting one, is what if my licensing model is old or outdated? So I think this is sort of referring to a situation where a customer has an old legacy contract, maybe with Oracle or IBM, where the licensing rules have changed, but they haven't, you know, they haven't upgraded or whatnot. How do you, how do you handle that in an audit?

Sure, sure. So let's dive into kind of what happens from an audit perspective from the auditors and then talk about how do you thwart this or handle it in it. So I guess the first thing to note is that your license is your license. If it's a perpetual license, the rights and grants that you're getting at the time of purchase are maintained unless you agree otherwise. So what tends to happen in audits is that auditors don't really know the legacy of 30 plus years of entitlements or software grants and they default to what it is. Now this can be problematic for clients that have legacy licenses because as time has gone on, the grants have actually changed. But also they're not changed for the benefit of the end user. They tend to favor the publisher more than the end users and they tend not to clarify certain things that are known to be gray and cause confusion when counting.

So that's, and I would just add to that that the process still is the process. Right. What you need to understand there is that in that case, if you've got an old legacy contract with an old license metric, that process that we put up, you're still going to run through that same process. The key is making sure that when the auditor. So if I put that, if I put that slide back up here, the key is when you get into this data collection and data analysis and validation phase is making sure that the vendor understand that your contract is based on that old metric. And the way that they need to collect the data and review the data is based on the old metrics. It's not based on, you know, whatever it is currently. Right. So I think, you know, what you do is the same. I think that the onus becomes on you a little bit more. Like, I would not sit back and wait for the auditor to come in.

And.

Collect data, do an analysis, and then go back and say, oh, by the way, we're running on an old metric. Don't assume that they know that and make sure that, you know, that's talked about in the scoping and kickoff. Make sure that you talk about. Well, because of this, you know, you need to make sure that you're collecting data based on this metric and that you're now analyzing it based on that metric. Right.

That calls out a good key point, Mike. Right. So actually I would say in the scoping and kickoff, that needs to be called out. And we don't proceed to data collection until it's established how your measure, measuring and what contracts and agreements these are stemming from. One of the tips and tricks. One of the things that I always do is I ask for a double signed copy of the contract and agreement that these licenses originate from and how they've materially changed over time. So this causes a lot of frustration from auditors because they don't always have that, but it's their onus to have it. If they're going to hold you accountable to an agreement, they better have it in, you know, a written copy. But in the scoping and kickoff, you should be defining what, where does the license originate from and what does that look like in terms of the language in that? Because they are, they, they do change. We see that all the time.

Absolutely. So let's, let's move to the next question. So one of the next ones, and this was another kind of, we got a Few different variations of this. But it's like what's the current trend globally that we're seeing on audit particularly sort of post Covid and as the world comes out of the pandemic. Right. So what is it that you're seeing? What observations are you making right now?

So let's talk about. During COVID we saw a little bit of a decline in audits. There was push off, delay, push to the right coming out of COVID as the economy restarts and starts to go back to normal. At least I'm personally seeing more and more audit or audit like behavior and we'll probably touch upon that later what audit like behavior is, but not a formal audit. So it's on the upswing in my estimation. But the targeting is a little bit different than 10 years ago. Most organizations are not going after the massive Fortune 100 companies, 10,000 plus employees. They're actually going after the small and mediums because they've already tapped in 10 years ago to the Fortune 1 hundreds. They're going after now Fortune 5 hundreds and below. And so they've recognized that that's a revenue base that they was untapped and so now they're tapping into it.

I agree. The same sort of thing, audit behavior, a lot of it was paused. It is starting to kick up. We are seeing it more so in the mid to low end of the enterprise space. Although, you know, we've seen it in a couple of large enterprises as well, particularly if they got some of those triggers like M and A going on. But the other thing that I would would add is maybe not even, I mean, I don't know if it's so related to the pandemic. But as a little bit of the economy tightens as well, we are seeing certain vendors that are really picking up that activity.

Right.

Like, you know, brocades broke. It's probably a prime example, Right.

Where.

You know, their business model is kind of purchasing software companies that have legacy technologies and legacy models and they're using it as a revenue generator. Right. So I think that's something to watch out for.

Yep.

I mean, sure, go ahead, Chris.

Yeah. In fact, you should. One of the things that I look at is what big companies are buying or software companies are buying other software companies or which PE firms, private equity firms are buying software companies. Because there are certain PE firms, that's their playbook. They buy an older technology stack or software company and they start to audit. And you don't hear about it a lot because they are very selective on how they do that. But that's things that I look at in the broader software world.

I think that's a key point as well. So I mean other than the process that we just talked about, is there anything else that you would suggest that people do to prepare for an audit?

Yeah, so let me. This is a little bit ad lib but this process should be linear. But if the auditors have their way, it is not. And so one of the things to kind of tips and tricks here is make sure it's linear. You don't want to be going back to data collection after you've had the analysis. You do not want that. You want to set the scope. You want to make sure that they have it written and that you move forward to data collection then to analysis. The challenges that we see with clients, you know, when we're not involved is it's go back to the, you know, the lake and fish for some more non compliance till we hit our number. That's, that's inappropriate. You know, no auditor is going to tell you that's what they're doing, but that's tends to be what they do. So if you're involved in an audit, make sure that this is linear and you get sign off on each of these milestones.

Yeah, I think that's a good point. I mean this process, I mean we could literally spend an hour or more going through each of each of these steps, right. Like there's a lot of tips and tricks that go into to each one, you know. So for instance before you get into scoping and kickoff, get an NDA put in place. And there's reasons for that. So a little later we actually we created a digital training course that goes through each of these steps. So I'm going to put up an offer a little later that for people that want to learn the deeper processes in here that they can get a special to pick up that course. But there is a lot that goes into each one of these steps and so understanding the nuances of them becomes very important. And that's why it's hard to get across everything that we would love to on a call, you know, an hour long but you know, so just note that there are multiple pieces that go into each one of these steps and things that you want to, you want to be careful of. Right. In the care cough we highly recommend for instance that you set a single point of contact, right. That the auditor is only allowed to communicate through that person whether that's around, you know, what data needs to be collected and things like that, so even if that person is not, you know, the administrator of the system or whatever that's going to collect the data, that the request has to go through that and then they go internally and get to those people because the auditors will ask for things or people will, you know, potentially inadvertently send something that maybe they shouldn't. And it's not that you're hiding things. I'll give you an example of what can happen. We had a client that was being audited, it was by Microsoft, and they allowed the auditors to go straight to an administrator to get some information on SQL Server. And they sent over a report on SQL Server, and there was nothing wrong, wrong with the report that was sent. But the problem was it didn't have the context. So it didn't have active and passive clusters. It didn't have dev and test servers identified. It was missing additions. And so the auditors got that and then came back and said, oh, you owe us like $30 million or you owe Microsoft $30 million. And it was like it became this big problem because something was given that was out of context, where if it hadn't gone through the single point of contact, they could have look it and said, well, we know that we need to identify our dev and test servers because that's part of our process. We know we need to identify passive and active. We're not going to send without versions being known, so let's go back and get those before this data goes over. And so, you know, that's just an example of why, for instance, you want to have a single point of contact. It's not to limit the auditors from talking or getting information. It's to make sure that things like that don't happen.

Right. So this another piece of that is that it's actually probably better. The most successful audits that I've worked with clients through is get somebody that has nothing to do with the underlying technology, make sure that somebody from the business side that it's able to have those conversations. Because I love technology folks, but sometimes, and I do this all the time, is I get into the specifics of the situation and that's not what's needed. We need the broad strokes and the authoritative view on things.

Yeah, absolutely.

So that's another nice trip tip.

And so then, yeah, so let's talk about one of the next questions. It's sort of around in the data collection section here, Chris, is like, how is software usage determined during an audit? And I know that, I know, I think, you know, that gets asked as what I think you know, is thought of as a simple question like how does usage get determined? But I think we're about to find that it's not. It's not that simple, is it?

Well, it's simple for me. Usage doesn't matter, period, full stop. Except in very select usually engineering where it's based on concurrent licensing. So depending on your metrics. But for the most part, usage doesn't matter. Doesn't matter if nobody's using it. If it's present, you have an obligation, or at least that's the position the publisher will have. So I think there's a misnomer here. Usage. Don't think of usage, think of presence. And that would be my state. Now, usage is important for the business to understand the value of it and what they can do and the cleanup that can occur. But from an auditing perspective, I would take that out of the vocabulary. It's either there and requires a license, or it's not there and doesn't require a license. What are your thoughts, Mike?

Well, you kind of keyed in on the word usage, right? You're looking at is it being used? And sometimes people consider that around like metering. So in other words, again, I'll pick on Microsoft just because that's my kind of expertise area. But I've got project installed out there. Is it actually being used? Can I meter it? And those sorts of things. But I could also look at this question and say, okay, instead of usage, if we change that word and said, well, how are they going to measure if we're compliant, right? And so that changes the conversation and this, that. And I bring this up as a real, on purpose, right? Because the words you use with the auditors can mean very different things, right? Where Chris just keyed on, on usage meaning am I actually using it? I may be key in on that as how do we measure whether. How we're. How we're licensed, right? And so you have to make sure that you're clearing your communication as well because it's very easy for vendors, auditors to take things out of context, right? I tell people all the time, like do not never say the word VDI or the acronym VDI to Microsoft. Because if you say vdi, they see five licenses and depending on how you're doing vdi, it could be two or it could be five.

Right?

And so you have to be, you have to be careful in the language that you use when speaking, speaking about this stuff. But if we look at it from a how do, how do we Determine how I count perspective. It always goes back to two things. It goes back to your contract and what your contract states and to the vendors equivalent of product terms or use rights or product use rights or per right that you have to go back and look at that. And so, you know, depending on what that is, that's going to determine how you actually go and collect data. Right? So if you look at what the different usage metrics, so to speak, are, you know, you could have processor core based license, user based license, device based license, you know, pv, EU based licenses, power units, there's all kinds of them. There's hundreds and hundreds of metrics. And so how to determine that in an audit? The first step is to look at your contract and see how is that measured, what is the metric that's being measured. And then you have to figure out in the data collection phase how best to get that measurement. Right. And so that's, that's, you know, it's very difficult to answer that because depending on what vendor we're talking about, that's going to be a different answer. And even if two vendors have a definite, like if two vendors have a processor license model, do not assume that vendor A and vendor B define processor the same. Right. And so that's, people fall down a lot because they'll be like, well, Microsoft defines processors. This, this vendor is doing processors. So I'm counting it the same way that Microsoft does. Well, that could be a big, big mistake. You need to actually understand the definition based on that vendor's contract and use rights.

Going further, you probably actually need to look at the product. Right? So one of the tips here is that Oracle defines a processor differently for an enterprise or database. Enterprise and standard. So the metric on a contractual level will say processor, but when you look at the products specific, it'll be a physical processor or it'll be a physical core. And then there's a, there's a ratio applied to it called Oracle core measure. But the point here is that you need to define that. And again, it's good to do that upfront in the kickoff and scoping and don't let it go forward until that's been defined and get them to do the work on it. You don't need to. You can just look at it and then disagree or raise concerns if you see it differently. But it's better to do it upfront than when there's a finding, right?

Yeah, that's a good point, Chris. So if we move on to the next question we were asked, one of them Is like, what sort of, you know, we're jumping down into the settlement discussions with this question. That's why I left this chart up. Because everything that we get asked falls into one of these buckets. But you know, what effective strategies are they used to use with a supplier when there's a need for license swaps?

Right.

And you know, can you look at doing multi year licensing commitments in order to, you know, kind of settle out of these things? Or if you got problematic licenses that you can't use anymore. Do you have any suggestions, any suggestions around that?

Sorry, can you restate this question, Mike?

So I think really what they're asking is, you know, what sort of negotiation strategies can you use with suppliers, particularly in an audit when you need to change license metrics.

So this is a complex one, but for the purposes of the first portion of an audit, you don't want to be doing that. That opens up ambiguity in the settlement is when you would probably look at doing that. A prime example is on the Oracle side, moving from nups to processors or processors to nups. The way to do that is to introduce it as a business value for Oracle or the publisher, right? Why it's required. Like you need to document the business reason for it as opposed to say, we just want to do this or it'll cost less. You need to show them why the value is there. They'll probably realize that it's to your advantage to it, but you need to articulate that.

I think that's a good point, Chris. I mean, that definitely is getting into sort of deep negotiation strategies. But the thing that I would say is on this is Chris is right. That is not something that you want to be bringing up in the scoping data collection analysis phase. That is a settlement discussion. And you know, the key thing is here, some vendors have policies, right? Like I believe Oracle has a policy where they'll convert a number of nups to processors. Other vendors do not have policies around that and they'll just tell you you can't do that. And then that becomes a negotiation. And the way to be successful in those negotiations is to be to take it back to business value or challenges that the vendor will have or that you will have if you continue down that route. If you go at them and say, well, if I convert these licenses, I know that I can save a million dollars a year, they're just going to say no to those. Now you can get that conversion and still save that million dollars. But that is not how you build that business case. It's all around business value, around the partnership, the relation, that sort of stuff. So you can definitely weave those into settlement discussions, but you have to position those with a lot of thought. Right.

And don't do it until the settlement. Right. Telling the auditors or working with the technical team collecting the data that is not their goal is to collect accurate data and create a leverage position for the publisher. It's not to get you the best deal. So settlement goes a little bit differently. But introducing ambiguity throughout the process is not the goal of the audit from an end user perspective. It's to create as much clarity as possible. Right.

And I agree and like the one thing that I will say about, you know, kind of just a little bit off topic, but an important point to make is that typically what we see in an audit, I'm just going to use a big number that's easy, $9 million. Like let's say there's a settlement finding, a $9 million that comes out of the accuracy and review comes out of the data analysis probably. Typically what you're going to find is a third of that's just wrong.

Right.

Like it's just, it's wrong. There's mistakes in the data, there's been assumptions made and you need to figure out why that is. A third of that is probably things that I, as I refer to them are gray areas. The licensing rules aren't clear on what you can and can't do. You know, there's a variety of reasons why, you know, an auditor can't make a, make a call on whether you're compliant or not. So they're going to basically say you're non compliant. And then a third is typically growth, which is really an audit finding. So that's the one thing too is particularly where they're calculating if there's penalties and stuff like that, you need to make sure that you call out what is actual growth. And those are true ups, not audit findings. Right. Because in that $9 million, that finding of 3 million, that's a true up, is not an audit finding. That's your contractually allowed to place that as true up. Right. And so you want to make sure you call that out. And so your goal before you hand off is to get rid of the $3 million. That's just wrong. Right. So you don't do a handoff until that 3 million is out. And then what's left is, you know, 3 million has been declared as growth or whatever that number is. And then 3 million is the gray area. And that's what you're going to go and negotiate on is that 3 million. And that's where you hand off there because an auditor won't make a call on the vendor's behalf. So if it's somebody like that is not the vend that's doing the audit. They're not going to make a call on that stuff that's going to have to get handed off to the vendor. But you want to make sure that that's what you're negotiating on.

So.

So let's move on. Oh, go ahead, Chris.

Well, one of the things that just came up when you were talking about the assumptions is get, get. If it's a third party auditor, particularly the accounting firms, ask them to state their assumptions in writing. And the reason for this is there's multiple reasons, but it has to do with accounting standards. They need to write them down and they need to go through, validate that those assumptions make sense. So reason I asked for that always is you're able to see what they're thinking and then you can debate it later on in the settlement if needed or challenge it beforehand. But the point is get it written.

Yeah. So I think the next question here is, you know, how strict are they about enforcing the small stuff like not having the correct country of usage listed within an audit?

It, I mean, how long is a piece of string? It depends on the vendor. There are vendors to be aware of that are very strict. I mean, it's a rule, you know, one that comes to mind is Autodesk. And the reason for that is that there's, there's some history there. Actually. It's because at one time the BIM software had restrictions on the IP where it could be used, but now it's basically an audit finding. And most people don't control software based on where it's installed. Right. And so it's an easy one for them to go after in terms of dollar value and create a leverage position. Other company or country or companies or publishers are less of an issue. It really actually goes back to a taxation rules. So like Microsoft, the reason they break it down into countries is mostly due to taxation and account credit as opposed to, you know, you're not allowed to use, you know, a subscription in Latvia if you bought it in Moldova.

Right.

Like it's more of that. That's my understanding at least. Mike, what are your thoughts?

Yeah, yeah, I mean, from a country of usage perspective, I would say, yeah, it's definitely vendor specific. One trigger that you can find is depending on how that vendor operates globally. Right. Like microso is an example of a software publisher that operates fairly well globally, right. VMware operates regionally. So VMware North America and VMware Europe, for instance, are two completely separate entities. And so with them it becomes important because of lots of different reasons. So that is vendor specific. The other thing they didn't specifically say in this question, but they said around country of usage. The other thing that I would definitely say here is, you know, it's not just country of usage. It could be little things like having professional editions license, but installing standard editions. It could be things like having OEM versions of software out there on your desktops in a corporate environment that maybe have restrictions. Right? And so, you know, there are things that pop up. So if you take Microsoft, for instance, you know, whenever we even just doing internal audits for people, you know, we're always going out and like, hey, you've got a bunch of like Home Edition or Student Edition or Business Edition that's come in through a purchase of a laptop or desktop on the oem. But you know, the EULA says that you can't use that, so you need to get rid of it. Now, in an audit, what do they do? They claim that you need to go out and buy a standard or a pro license of Office for that. And usually that's one of the things that you negotiate out, but they become annoyances, right? So, you know, again, it's hard to say because it's vendor. This is vendor, vendor specific, Right? Like Corel, for instance. Instance, because of the nature of a lot of their products being installed, oem, they're looking to see if you reimaged and installed that product on machines that didn't come with it.

Right.

And so that could become a very serious thing with a simple mistake in a Corel audit. Right. So again, it really depends. It depends is the answer.

Right?

But there's definitely clues that you can get based on how they are set up, how, how their licensing works, where do they drive most of their revenue from, those sorts of things. Right. So next question here, Chris, is which vendors incentivize their reps for revenue derived from audits?

So tough question because I don't know exactly how it's compensated, but there's direct compensation and indirect. So a good example of direct compensation is around Oracle. The account team get incentivized by any order placed as a settlement to an audit. Indirect is like IBM. The account team does not see incremental benefit on the initial renewal or, sorry, not renewal, so the purchase, but they will See their accounts grow based on renewals. And so I believe every publisher incentivizes the salespeople, but it just may be direct or indirect.

Yeah. And so I would say if it's a publisher, a publisher initiated audit, somebody at that vendor is getting paid for it. Most of the time the sales teams will get quota retirement from it. But some vendors are set up where the audit teams are responsible for going to drive X millions of dollars of revenue and they'll get credit for it. Where things change is when it comes in through like the bsa, the Business Software alliance and things like that. Because in those cases the software publisher doesn't even get the revenue. Any findings that come through the bsa, the BSA takes that revenue. And so I won't get into the BSA today. But you know, just if it's a publisher initiated one, it's probably there. If it's a third party initiated one, nobody on that vendor is getting paid. And those ones become more difficult because the BSA is out to find money. Right? Like that's their whole purpose. So I did put up, just so people know the digital training where we go into each of those steps in more detail. You can go to the link on the bottom here or take a picture of the barcode there, QR code, I guess, and it'll take you to the link. And if you use the Software Survival 2022 on checkout, it drops the price to 200 bucks from what is regular $1,000 on that. So Chris, next one is if you were published, if you were audited, I think the question here, I'm going to kind of paraphrase this one a little bit, is if you were audited five years ago and they only found like minimal to no findings, and the same auditor comes back five years later and wants to audit it again, can you get that dismissed stating like the last time you audited us you found nothing and you have, you know, and you even have more controls in place than you did last time. Like, so I think this question really is, you know, we were audited in the past. There was no findings. They've come back. Can we, can we stop the audit? And we actually one of the other questions that we were asked is, is can we cancel an audit? So let's maybe kind of combine those two in our answer here.

Sure. So from a contractual perspective, they have the right to audit you unless you've changed the underlying contract. What we tend to do is in a settlement, bring forth the idea of a non audit period, a cool down period, three, five years. That is a smart thing to include in the settlement so that they don't come back six months later and do the same thing or a year later or two years later. So that's the first thing. The second thing is you can absolutely get or have software audits removed, but it's not going to be, I was audited five years ago, I don't want to be audited now. You can't audit me. It's going to be a business conversation on, do you want to go down this road? You found $1,000 last time, it probably cost you 30,000. And we have more controls and we know we're compliant. Right. So you need to paint the picture. So how I would do it is I paint the picture of there's no money here. You know, if you're just doing this randomly and want to waste money, let's go for it. And we have this under control. And this brings in the notion of like, you probably want to make your software audits as painful for the auditors as possible as well. You want to be truthful and accurate, but you want to make sure that, that if they're playing games with you, that you're making sure it's as costly to them as possible because they use this as a revenue generating activity. So as soon as their costs exceed the revenue, they do not tend to target you. So that's a point that I will.

And it's not even, I wouldn't even say it's cost. They're looking for an roi. So when their ROI goes below what they're looking for, but that actually adds another point that I would sort of add. Can you get these things pushed off? Yes. Right. It's a negotiation. Everything's a negotiation. So you could negotiate to get it pushed off. Now you have to have really strong business reasons, business reasons for that. And you know, will it work? Not always. Not all vendors, but we've done it many times or you know, had them change from a formal audit to a self assessment where you just deliver them, you know, results that you produce internally. They validate that they're okay with those and they accept it. So there are a few different things there. One of the other things that you sort of triggered on me, that's not in this question, but I'll bring it up, is you should be reading the audit clauses in your contracts to understand what the vendor's rights are and what your rights are. Right. So, because sometimes an audit, like with Microsoft, for instance, if you're found to be outside of compliance by greater than 5%, they can charge you for the audit. Now, they don't define what 5% is, is that revenue, license number, whatever. And so that's something that, in that kickoff, you want to make sure that that's defined. Other ve, you know, the audits are performed at their expense only sometimes they're performed at, you know, your expense only. So, you know, you want to make sure you understand that because that, that is definitely something that could, could get factored, factored in there as well. So the next question that we got, Chris, was what, what rights do I have to protect myself when I receive an audit letter? And how much time is reasonable for, for me to respond?

So whatever rights were in your agreement is what you have. Doesn't mean you can't negotiate them. But so for Oracle, you have 45 business days to respond to an audit for other vendors that the terms will.

Differ or they're not defined. Right.

Or they're not defined. And if they're not defined, then the gray zone is on your side and you can say, we're busy. Business operations take precedence and we'll, you know, we'll get back to you in X amount of days. But what you don't want to do is just forget about it. If you g. File the audit letter, you're going to have problems. You do not want to just ignore them.

Yeah, don't, don't, don't not respond to them. Yeah, that is.

And acknowledge it. And then let them know what your.

Timeline is and that, that the timeline thing is key. Like, you control the timeline, not them. I don't know how many times I've heard auditors come in and say, oh, we're going to be done in 30 days. And I just laugh, go, okay, this is going to be a 9 to 12 process. Right. Because your environment's not simple. It's complicated. They're not going to understand it. You know, lots of, lots of reasons. Right. But, you know, a good thing to do is to, you know, like I said, we like to stall about two weeks, typically by putting an NDA in place so that if the audit's going to go through, that you can go ahead. And so words I want to use here, Chris, start preparing internally before that process kicks off. But yeah, so you want to respond, you want to respond in a timely manner. Like, even if it's just, I've got the notification, you know, this needs to go internally to a few people. I will get back to you asap. Right. And then, you know, Whether you got to send that to legal or you know, wherever you need to send it to start that process, just acknowledge that you've received it and then, you know, in the scoping and timeline, make sure that things are reasonable. Right. Like I don't know how many times we've seen audits. Like it's like, okay, we're going to audit you, Mr. Retailer in the month of December. Right. And it's like, okay, our busiest time of year. No, it's not going to happen. You know, can we push that to March when things slow down or you know, whatnot. So you can definitely have conversations like that. But yeah, go from there. I know we talked about a few of these, Chris, but who are you seeing, you know, actively audit right now?

Well, our friends in Big Red, Big Blue we're seeing actually, strangely enough, I'm seeing some Microsoft, the engineering software seems to be on the upswing for auditing, but there may be some other economic reasons for that. And then Corel, for whatever reason seems to be hot button. They, they want to make their revenue from it. All the major, the usual suspects as I call them, are doing it. I haven't seen actually a micro focus in 12 plus months. Doesn't mean that they're not happening. I just haven't seen them. But that's one that is particularly challenging. They were acquired by a PE firm and I'm sure they are doing it. I just don't see it.

Yeah, I mean I would add probably Veritas, Brocade, Adobe to that list. Citrix.

Right.

Those are, those seem to be the main ones. But you know, we are seeing that. We are seeing some strange ones too. Like just, you know, weird. I'll call it weirdwear.

Right.

Like just small software publishers or SaaS, vendors that are pushing these, particularly if the revenue is slowing or you're, like I said, moving away from them. Right.

So yeah, one thing to call out here is that what we're not seeing, you know, there's a lot of marketing material that Oracle's auditing Java. We are not seeing that. And I have no intelligence across both EMEA and North America that that's occurring doesn't mean that one offs aren't occurring. But there is not a formulaic program at Oracle to audit Java.

Right. Okay. Yeah, no, I think that, that, I think that's consistent with what, what I'm kind of seeing. So let's talk about one in the data collection area, Chris. Like can I, can you trust auditor scripts? And does it, you know, does it pull, do they only pull the required data.

I guess we go back to my, my time at the defense contractors. Trust but verify, meaning, you know, you can trust their scripts that they're going to collect what they need but verify what they're actually collecting. And what I mean by that is typically they will collect more information than they need to complete their required tasks and it may not be advantageous for you to use their technology. Let me go into that a little bit of deep or more so. Like for instance, our friends at Oracle have verified tools across ServiceNow and Flexera and a bunch of other tools, but this is actually a little bit of a bait and switch because those tools collect more information about your environment that they, you know, when they hand those files over to Oracle, they get a bunch of, you know, additional marketing information, what products you're using, etc. So to answer that question, trust but verify, they will collect it if you, if you run their scripts but verify what they're sending and whether it's appropriate and reasonable. I hope that answers the question, Mike.

But yeah, no, I mean, I think that's a good point. I mean the thing I don't like about the auditor scripts are quite often they're not useful for you, right? Because a lot of the times they're pulling stuff manually and then they have teams of people that then go and stitch all that data in the background together to create their license positions. So I'm a big proponent that if we get audited, or particularly if they're one of the softer cousins of an audit, like an assessment or whatnot, which are really just audits in disguise, but you should be doing things that work within your processes and your existing tools because most companies, like 99% of companies out there want to be compliant and they have tools and processes in place that they believe are working. And so if you're going to go through an audit, you want to validate that your stuff is working, not use some third party script that you can't, you can't use, it's not repeatable for you, that sort of thing. And so, you know, in addition to what Chris said, that's the big thing for me is like why do I have to run your scripts when, if I want to do this next year to make sure that we're, we're, we're still compliant internally, I'm not going to know how to repeat that process. If I use, use your scripts, I want to use what I have. I want to, I want to identify any gaps that exist in what we have so that we can figure out how to close, close those gaps. Right. So that's, that's kind of my, my big thing. I mean I think most point, most of the time, especially the third party auditors, you know, they're not trying to do anything nefarious, that's the word to use. But like Chris said, they're going to grab information that maybe they don't need and you know, grabbing that information that maybe they don't need could lead to a misinterpretation which causes, causes challenges. Right. So. Okay, so I think we got maybe time for, for one more, Chris. I don't know if there's one that you can think of off the top of your head that you want to, you want to hit on or I can just ask one more here. I have a good one, I think I have a good one that we haven't, we haven't really hit on. How do I make an audit team? I think that's a great question, right? What, what, how do I make an internal audit team? What, what type of, you know, who in our organization should be involved in that? You know, those sorts of, those sorts of things.

Darn. I was, I was thinking maybe one of the publishers were asking our opinion on how to better structure their audit teams.

But yeah, I would love to give a couple of them some advice.

But yeah, I've given them some advice. They don't listen to me. Not on that front. But if you're looking to do an audit team internally, like an internal SAM team that is going to do soft audits or internal audits, you want some folks that understand the contractual lens that you're in, understand the technology and that will be objective on any findings. Ideally they have background in auditing. It doesn't have to be software auditing, but accountants actually make pretty good auditors as they're good accounting once they understand the lens. But you really do need to know the vendor specific licensing, hiring and bringing in subject matter expertise like metrics data has on whole plethora of publishers is probably smart as you'll be able to get a quicker time to value on that. But you need to build those muscles. And what we found, or what I've found is that the best internal auditors are actually homegrown over time. That's where I learned it and then kind of have ventured out on my own and joined metrics. Right.

Yeah. And I'd probably just add a little bit of, a little bit of a different twist on that as well, Chris, is that you're probably gonna need a few different disciplines, right? So you're gonna.