SPLA Audit Readiness: Building a Fortress of Compliance

Alexander Golev: Welcome all our friends to another SAMexpert event dedicated to service providers of all kinds and everyone around the hosting data centre and SaaS industry.

It's always wonderful to see familiar faces, and if you're new, you're warmly invited to join us today. My name is Alexander Golev, and I'm a senior partner at SAMexpert, a boutique business management consultancy.

The somewhat pretentious tagline of today's event is "Building a Fortress of Compliance." What does it mean?

It's about always being prepared for a compliance audit by Microsoft and possibly even being able to prevent it entirely. Our senior partners, including Daryl Ullman, who is with me at the event, and I personally have extensive experience in Microsoft vendor management and audit defence spanning over 20 years.

In recent years, we have defended multiple organisations through over a hundred audits. It's always the same story. Service providers consistently have the same questions and concerns. They wonder why they are being audited and find it challenging to gather the required data. They question the need for specific data, such as billing records, and are surprised by the high penalties imposed. Despite their efforts to follow the rules, they often encounter knowledge gaps and are perplexed by the severity of the penalties.

The Operating Model for Licensing Compliance

It should be evident that having a proactive system in place, such as an operating model that handles contractual compliance on a daily basis, is better than reacting to such situations unprepared. This is a conclusion I'm sure you're already aware of.

Often, the source of the problem is that licensing compliance is not even among the top 10 priorities of service providers. We know you are working hard to keep your business running and to make a profit. We regularly communicate with our clients, monitor the market, and gather feedback through questionnaires.

We try to listen to our clients and monitor the market. We recognise that licensing often doesn't make it to the top 10 concerns. It did get some attention at the beginning of 2024 during the Broadcom VMware Acquisition. Managing licensing can be quite complex and challenging, causing frustration and headaches for many. The only time licensing reached the top 10 was at the beginning of 2024 with the Broadcom VMware Acquisition shenanigans. Plus, as anyone would admit, licensing is complicated. It's a headache.

That is why, today, we want to help you overcome that. We want to give you a relatively easy, tried and tested system that we help other providers implement, a system that you can copy and stick to, or build your own system based on our recommendations. We have been implementing and polishing this system with our key clients over the years. We've been learning from real-life obstacles and mistakes, not only in audits but also by implementing this system and these processes.

If you are interested in an audit readiness cheat sheet, please email us at ask@samexpert.com, and we'll send you a copy.

A Proactive System for Audit Readiness and Prevention

Now, let's dive in. I'll walk you through the foundational steps of the Audit Readiness and Prevention system and explain how it can help you avoid an audit. We often say that audits are almost unavoidable, but there are specific steps you can take to try and prevent an audit before it even starts.

Step 1: Understand Your Own Business

The first and most crucial step is to truly understand your own business. This begins with categorising your services, no matter how elementary it might sound. In our experience, many providers lack a detailed understanding of their own offerings. Don't take this personally—let me elaborate.

We have consistently observed that hosting and SaaS companies excel at developing, supporting, and selling their services. You're experts in your field, and your sales processes are top-notch. But what happens behind the scenes? It's not always crystal clear, particularly when new services are developed or rolled out or when a key customer requests something unique that you wouldn't typically offer. In the interest of retaining the customer, you might agree to provide the service, leading to the creation of a new offering. When it comes to compliance, there might be a general awareness of what's happening. Still, it often lacks the detail needed for audit readiness, full compliance, and especially for preventing an audit.

The first thing you need to do before we discuss data, tools, and scripts is to get a handle on all the types of services you offer. It might seem basic, but it's not always as straightforward as you think.

Let me give you a few examples to illustrate.

One of the most frequent types of service is dedicated hosting – also known as colocation, single-tenant hosting, or private cloud. There can be several variations of dedicated hosting, depending on who provides the hardware, the licenses, and most importantly, what licenses. We strongly recommend treating each of these variations as a separate service in its own right.

Next, we have shared hosting, also known as multi-tenant hosting or public cloud. Shared hosting also comes in different flavours, the most common distinction being between managed and unmanaged clients.

Managed clients are the ones where you provide additional services on top of simple hosting – you're the system admin and the IT outsourcer. You have access to their operating systems and domains, and maybe you even co-manage their entire environment. This can get rather complex, as there might be variations where you fully manage everything or just co-manage certain aspects. So, it's best to document each variation as a distinct service.

On the flip side, there are unmanaged clients. You have no access to their virtual machines – none whatsoever. They simply rent the machines from you, and you provide no services. No admin access, nothing. It's their own world to manage.

Here's another common scenario we come across, and it's not exactly in line with the SPLA rules. It happens when you provide SPLA licenses to a client but don't have access to their virtual machine. This makes it difficult to know whether they have enough licenses or what software they run. If this sounds familiar, document it as a distinct type of service you offer. Remember, we're not concerned with specific clients at this step in the process; instead, we are getting a comprehensive view of your service offerings.

SaaS hosting can be a bit complex, with a few common scenarios and its own cost-saving opportunities.

The first is when you're a SaaS company with your own data centre or renting rack space. You host your own application, you own the IP, you developed it, and it's in a dedicated environment. The good news is, you might not need SPLA for this! While you can choose SPLA, you could also opt for self-hosted volume licenses. This isn't common knowledge, but it can be a significant cost-saving measure if you have your own volume licenses.

Another SaaS scenario, if you're licensing applications or components from a third party, is no longer considered your SaaS application, and you will need to use SPLA.

Another interesting scenario is when a provider exclusively hosts dedicated environments for other SaaS providers. This can get quite complex, with different licensing requirements to consider.

Finally, we have some providers, often the larger ones, especially those working with governments, that offer full-fledged business process outsourcing (BPO) services.

So, what exactly is a BPO? Essentially, it's a scenario where the end client has no access to the systems, or perhaps only limited access through a web dashboard or similar interface. A typical example might be a fully outsourced call centre. When it comes to BPOs, there are additional distinctions to be made, depending on whether they are running on dedicated hardware or hosted in a public cloud environment.

Here's the key point: different setups can involve different licensing scenarios and requirements. That's why it's crucial to document each of these services separately. When an audit comes around, you'll be fully prepared, knowing exactly which environments and details fall under your responsibility and which licenses are required. Remember, some of these services might not even fall under SPLA, while others might have varying bring-your-own-license (BYOL) requirements.

Recently, we've also been supporting hosting providers in building new cloud environments specifically for CSP hosting licenses. While it's not technically a distinct hosting scenario, the licensing requirements are entirely different. From licensing and billing to management, it's a unique service with its own considerations. So, it's essential to have a separate entry for this in your list of services.

Be as detailed as possible, documenting every service and every variation you offer. You need to have a comprehensive view of your services. It is your first crucial step to "build a fortress of compliance".

Since the whole purpose of today's event is to help you build a long-term operational model for audit readiness, we're not just talking about a one-off, quick fix for when you get that dreaded audit notice. We're talking about being prepared and having a system that keeps you always ready, regardless of whether an audit is looming.

The beauty of this approach is that it not only makes your life easier if an audit does happen, but it also significantly improves your company's financial stability by providing greater transparency and a clearer view of your operations.

To maintain this clarity, you'll want to review your list of services regularly - at least annually, but possibly more often if your organisation is rapidly changing. A quarterly check-in tends to strike the right balance.

Step 2: Diagram Your Entire Infrastructure

Once you have a firm grasp of your services, the next step is to map out your entire infrastructure. And when I say entire, I mean entire. We're not overlooking anything here, not a single cluster. Instruct your IT department to provide a complete list of every location, data centre, environment, and cluster you have. This is how we do it, our tried and tested method.

For each cluster, you need to specify exactly what types of services it's used for. Remember the list of services you just created? For each cluster, you'd note something like, "This cluster is for a dedicated client who brings their own licenses except for operating systems." You need to be this granular for each and every cluster. If it's a dedicated cluster, you also need to write down the name of the client it's hosted for. You need to know precisely who owns what.

Make sure to perform this exercise regularly. Depending on how much your setup changes from month to month, you should do this at least quarterly and possibly even monthly if you're making many changes or migrations. As soon as you deploy a new cluster, it must be added to the list immediately and managed accordingly. Think of it as a high-level overview of all your clusters. It's crucial to have this well-documented. And that's just the basic requirement for knowing your infrastructure.

While you can initially skip this step, it's important to eventually have a database, or Configuration Management Database (CMDB), where each virtual machine is clearly assigned to its purpose: internal use, demo, trial, or a specific end client.

This level of granularity is your ultimate goal, but starting with the clusters is key, as that's where the main problems usually arise—lacking a well-defined scope.

Step 3: Compile a List of Your End Clients

Once you've completed the previous steps, it's time to create a list of your end clients. You probably already have a CRM or sales system you use to manage client relationships, so stick with that.

Here's what you need to record in that system: all the compliance-related details for each client. What exactly should you track? I'll simplify it and give you the basics.

First and foremost, the type of end-user agreement. Did the end client accept online terms and conditions? A service start date should be recorded, which can help you determine which version of your terms and conditions they signed. Why does this matter? Because when a client signs those terms and conditions, they agree to a specific set of terms.

And if you have indemnity clauses in there – the ones where they agree to cover you if Microsoft comes knocking with compliance claims when they're the ones responsible for their software – it needs to be crystal clear in the terms and conditions. You need to know exactly what they signed. We're emphasising this because, in an audit, if you start pushing back on those claims, auditors will demand evidence that the client signed a specific version of the terms and conditions and want to see the exact wording.

For each client, you need to know exactly what they signed. If they have a custom agreement, make a note of it. If it's a standard services agreement but not an online terms and conditions, keep a written copy in your CRM. It's your best defence when questions arise.

Remember, the more information you have readily available and manage on a daily basis, the smoother the audit process will be.

Other essential details include whether the client is managed or unmanaged, as this difference significantly impacts your responsibilities.

And don't forget key milestones like service start and end dates, demo and trial periods, go-live dates, and the specific licenses you provide. Crucially, you need written evidence that the client has accepted responsibility for the licenses you don't provide.

Scouring for this evidence in the middle of an audit, when you're already stressed and under pressure, can be one of the most time-consuming and frustrating aspects of the process. So why not gather it beforehand? Make it part of your standard operating procedure.

Yes, it might seem like an extra burden on your day-to-day operations, but you've chosen to host Microsoft software, and with that comes certain responsibilities. I'm not defending Microsoft here, not at all. But you did agree to their terms and conditions, so the best course of action is to adhere to them.

This list isn't set in stone; it may require monthly reviews. Clients often request new services, deploy new software, or even switch from unmanaged to managed. Things change, and it's better to update your records reactively as these changes occur.

Ideally, you should modify your existing processes to accommodate these updates. We're talking about your standard processes like pre-sales, sales, client onboarding, change management, upsells, and offboarding. Whatever processes you have in place, ensure that any changes relevant to compliance are accurately reflected in your client list and change records.

Now, let's move on to another interesting topic.

Contractual Compliance: Beyond Licensing

So, you've completed all of that. You have your list of services, your list of clients, and all those essential details. Now, let's shift our focus to contractual compliance. There are certain aspects of SPLA and CSP hosting that may not directly relate to licensing compliance but still indirectly affect it.

End User License Terms (EULT)

First and foremost, SPLA requires every end user to sign an End User License Terms (EULT) agreement. While there's no direct monetary penalty if they don't, it's still crucial for your protection. The EULT is a PDF provided by Microsoft along with your SPLA agreement. It must be fully included, without any changes, in your Terms of Service. While Microsoft's language states "at least the terms that are in the EULT," our recommendation, based on experience, is to simply include it as is. Don't modify it; just add it as an appendix to your existing terms and conditions or master services agreement.

Now, why is the EULT so important? Let's break it down.

First, it clearly communicates to your end clients that they are responsible for using Microsoft software compliantly. By signing it, they acknowledge this obligation. This helps you immensely in case of any disputes. The EULT also requires end clients to collaborate with you during an audit – and that's in writing. Don't underestimate the value of this document. If there's a dispute between you, Microsoft, and an end client about who's responsible for paying for a license discovered during an audit, the EULT gives you the leverage to point to the client. Of course, you need to handle your client relationships carefully, but this contractual right simplifies your position.

So here's what you need to do: as a one-time task, review all your existing end-customer contracts and update them to include a copy of the EULT. Then, going forward, update your sales and onboarding processes to ensure that all future clients sign the EULT, either by accepting online terms and conditions or by physically signing your master services agreement.

Additional SPLA Contractual Requirements

There are a few more contractual requirements for SPLA that you need to follow. Again, adhering to these will simplify your life in the event of an audit or verification.

SPLA mandates that you report details of end clients whose consumption exceeds $1,000 per month. Here's an interesting tidbit: depending on your SPLA version, you may or may not need to report their consumption per client via separate enrollments. Listen carefully, as this is important: for a few years, this was a requirement, but recently, SPLA dropped the need for detailed reporting with separate enrollments. However, not all resellers have informed providers of this change, so if you've renewed your SPLA recently, double-check the language in your agreement.

If it doesn't explicitly state that you must report separate consumption, you can stop doing so. However, you are still required to report the contact details of those high-consumption clients. That requirement remains in the SPLA. You just don't need to provide Microsoft with a granular breakdown of their license consumption, and you don't need to create separate order forms. It actually reduces the administrative overhead on your end.

SPLA also requires you to track details of all demos and unpaid trial access you provide to end clients. Here's the good news: if you're demonstrating your solutions or offering unpaid trials, those licenses are free of charge from an SPLA perspective.

You don't have to pay for them, but you do need to prove it. Microsoft requires written evidence of these instances, including client details. It's all there in your SPLA agreement. You simply need to keep records to avoid being charged for those licenses. It's not complicated.

Just make it part of your standard process. Ensure it's integrated into your day-to-day operations rather than being a separate task or review. It's just a matter of incorporating it into your existing processes to provide demos or trial access.

License Mobility Partnership Requirements

Next, if you're still a License Mobility Partner – and there aren't many of you left, as it's an outdated program – my advice is to not renew it. Unless you're Amazon or Google, it just doesn't make sense anymore.

However, if your participation in the program is still active and you allow BYOL, you're still contractually obligated to collect and keep license verification forms.

Remember, however, that even if you're no longer in the program, you'll still be asked for those forms if you get audited. So, as part of your audit readiness preparation, we recommend gathering those forms for all your clients, going back as far as possible, and keeping them organised and secure.

CSP Hoster Requirements

If you're a CSP hoster, you're also required to verify your end clients' licenses and report certain CSP-hosted Microsoft products quarterly, per the terms of the Microsoft CSP Hosting Program. So, as I mentioned earlier, make sure to update your processes to thoroughly follow all of these requirements, and conduct at least an annual self-verification to ensure you're doing so.

Bring Your Own License (BYOL) and No-Access Scenarios

By now, you've probably figured out that "bring your own license" (BYOL) is a big deal. And it is. It happens whether you officially allow it or not, especially when system administrators aren't fully aware of the compliance rules.

Even now, we still see people who don't understand the consequences of deploying SQL Enterprise instead of SQL Standard. BYOL is a serious matter, and if you've been following our work, you'll know that Microsoft holds service providers responsible for every single bit of their software in your environment. Whether you like it or not, that's their stance.

I'm not here to defend Microsoft. In fact, your lawyers might argue that in Europe, this kind of third-party liability wouldn't hold up in court. But contractually speaking, this is Microsoft's position, and they're not messing around.

From the get-go, before you even present any other evidence, you're held responsible for every single piece of Microsoft software in your hosting estate. If you've followed the steps I've outlined so far, you should already have a list of your services and end clients. This is a crucial foundation as we dive deeper into the BYOL issue.

Common BYOL Scenarios

When addressing BYOL, don't start with it immediately; complete all the steps I outlined earlier. However, once you reach this stage, let's explore BYOL scenarios in more detail. There are numerous possibilities, some involving BYOL and others not. Here are a few scenarios to consider:

1. You provide all Microsoft licenses to the end client via SPLA. Many providers follow this model.

2. You provide all Microsoft licenses through CSP hosting.

3. You provide some of the licenses and are aware of which other licenses the client is bringing into your infrastructure.

4. You provide some licenses but do not know what other licenses the client might be using.

   • You might have no access to their machines and provide no licenses at all.

   • You might have no access to their machines and provide only operating system licenses.

   • You might have no access but still provide SPLA licenses at their request (WARNING: not strictly compliant with SPLA terms).

   • You might have no access but still provide CSP licenses at their request.

The variations are numerous; this is just a brief overview based on our recent experience.

It's essential to meticulously track all licensing scenarios, particularly the complex ones, for each client in your end client register.

As you've likely inferred from our discussion, this can create at least two significant management challenges. First, there's the issue of clients whose machines you can't access, making it impossible to control or verify the software running on them. Second, there's the challenge of managing bring-your-own-license (BYOL) scenarios across all these different service types.

No Access to Virtual Machines

Now, let's address the issue of not having access to virtual machines. This can create a major roadblock during an audit because Microsoft, and subsequently the auditors, will demand that you scan all virtual machines, regardless of whether you have access or not. Yes, even if your agreement with the end client states otherwise.

We've heard rumours that Microsoft might have softened their stance on this, but there's no official confirmation, so it's best to assume the worst and be prepared to scan those machines.

But can you avoid this altogether? It's tough but not impossible. You need a compelling case backed up by solid, indisputable written evidence. Think of it as your nuclear option, something they can't argue with. If your evidence is vague or unclear, they'll push back.

If you try to argue verbally, they'll just keep pushing. And this can go on for years – we've seen it happen. They'll just keep coming back, month after month, asking, "Have you scanned the machines yet?" And you'll keep saying, "We don't have access." It's a frustrating cycle.

Your best bet is to provide as much evidence as possible, starting with your terms of service. You need to show, in writing, that you have absolutely no access to those virtual machines, not even a backup admin account. Your end clients must accept full responsibility for what they deploy on those machines and fully indemnify you against any claims. This includes acknowledging in writing that you're not providing any additional licenses beyond the operating system, or maybe not even that if they're using CSP licenses.

Don't expect to get away with a simple verbal claim of no access. It has to be in writing. If you've followed the advice I've given you – building your end client register, having solid agreements and change records in place – you should already have all the necessary evidence.

That's how this system works: it's built step by step. By the time an audit rolls around, you'll have everything ready to go. Present it up front, and be proactive. This is an ongoing process, not a one-time drill.

I'll be honest: it won't be an easy argument, but if you follow this advice, you'll be in a much stronger position to defend yourselves.

Managing BYOL

Now, let's discuss managing Bring Your Own License (BYOL). As I mentioned, License Mobility Partners and CSP Hosters have specific BYOL requirements and guidelines provided by Microsoft. If you fall into either category, simply follow those guidelines.

But what if you're neither? If you're not a CSP Hoster or License Mobility Partner, Microsoft doesn't explicitly require you to manage BYOL. However, during an audit, you'll face the same scrutiny as those who are. You must demonstrate that you and your end clients have distinct licensing responsibilities. In the simplest terms, this means clearly defining exactly which licenses you provide.

Furthermore, we recommend collecting evidence that your end clients actually possess eligible licenses. Auditors consistently ask for this, and it's much easier to have it readily available than to scramble for it during an audit.

However, it's debatable whether you need to act as a daily auditor for your end clients, especially when it's not a contractual requirement with Microsoft. That said, if you want to make your life easier during an audit, it's wise to politely require your end clients to inform you when they deploy Microsoft software that you don't provide. You can include this in your terms and conditions and request reasonable proof. It's a simple step that can save you a lot of trouble down the road.

Relevant Records and Documentation

Let's turn our attention to relevant records. This aspect of SPLA often raises questions due to the somewhat open-ended definition of "relevant records." The agreement doesn't specify precisely what they should be.

However, SPLA provides examples, such as billing records. It's strongly recommended that these be maintained, particularly in the event of a dispute. For instance, if a client who co-manages Active Directory with you deploys additional software or increases the number of authorised users without your knowledge, your billing records can serve as valuable proof of your compliance.

In such a scenario, your billing records can demonstrate that the client did not pay for the additional licenses, you didn't bill them, you were unaware of the increased usage, and you didn't profit from it. It clearly shows there was no intent to deceive Microsoft. Your records provide a clear link between what the client paid for and what was reported.

There's one thing we always recommend when it comes to relevant records. This should be the most straightforward step for any service provider, regardless of the maturity of your current license management processes: keep your monthly SPLA reports and quarterly CSP hosting reports organised and backed up.

In addition to the reports, we suggest maintaining the entire paper trail, starting with the report itself, including the purchase order (if that's part of your process) and the invoices from your SPLA reseller. It's crucial to keep a complete record.

Why? Because we've seen cases where a provider reports consumption for a particular month, say September. For whatever reason, it gets lost in the shuffle – maybe in an email or the reseller's system, especially if there's any manual intervention involved. Suddenly, it gets attributed to October, and Microsoft sees that you reported zero licenses for September. Sure, You can argue, but it won't be easy.

But you're in a much better position if you can prove that you reported correctly and on time. So, keep that paper trail intact. For most of you, this will be the most straightforward place to start getting your relevant records in order.

Inventory and Tools

Now, let's talk inventory and tools—your data. If you have dedicated, specialised tools for managing SPLA and CSP hosting reports, that's great! But the key is to make sure you trust that tool. It needs to be maintained regularly, and you need to be confident in the data it provides.

Here's a simple question we ask our clients to gauge their trust in their tools: "Do you use your tool as the definitive source for your end-client billing?

If the answer isn't a resounding "yes," it usually means there are some trust issues. We often hear things like, "Well, we don't track this or that," or "We don't trust the Visual Studio numbers," or "We forgot to exclude this or that." This means your tool isn't being fully utilised or managed.

So, as you build your fortress of compliance, establish a regular process for reviewing your tool's data. It needs to align perfectly with your client's arrangements. Remember, you've already documented your client list and services, so you can cross-reference everything. The goal is to trust your tool so completely that end-client billing becomes as simple as pushing a button in a system like Octopus Cloud.

If you're using your own scripts, it's crucial to remember that scripts that measure only one predefined thing can be risky. Your scripts, your data-gathering solution, should protect you from human error.

Let me illustrate. Suppose you have a client with a designated security group for accessing Microsoft Office. Don't just have a script that checks that specific group. Instead, have a script that checks all security groups. Why? Because mistakes happen. Someone might accidentally add other groups to the remote desktop service, giving more people access than you intended. If you only bill the client based on the designated group, you'll be underreporting to Microsoft and end up with a hefty bill during an audit.

Whether you choose to provide data directly from your tool during an audit or run the auditor's scripts instead – which can sometimes be a strategic choice – having a dedicated tool is undeniably beneficial.

Preventing an Audit

So, how does all of this help you prevent an audit? Let's start with this: when Microsoft decides to audit a company, they're making an investment.

They pay an auditor, usually around $30,000 to $50,000, for a basic audit. The longer it drags on, the higher the fees. They want a return on that investment, not just in money but also in their internal resources and the effort spent sending emails, chasing you down, and managing the whole process.

They won't get a return on that investment if they see that you're managing your environment properly. There are telltale signs that you're on top of things. For instance, if you report the exact same numbers every month, that's a red flag for Microsoft. It suggests a stagnant environment, and that's simply not realistic. In all my years, I've never seen a static environment. If your reporting is static, something's wrong, and you become a prime target for an audit.

Now, there's no guarantee you can dodge an audit entirely, but there are things you can try. For example, if they send you a notice, you could try reaching out and asking if it can be avoided. It's a long shot, but it's worth a try. Typically, once an audit is initiated, they'll want to see it through. But if you present a compelling case – maybe you mention that you work with a reputable partner to manage your SPLA – you might be able to convince them to back off. You're basically saying, "Come on, you'll just be wasting your time."

And even if they do go ahead with the audit, if you're fully prepared, your penalty might be minimal – we've seen cases where it was as low as a thousand euros. In that scenario, Microsoft ends up footing the bill for the auditor, wasting their time and money. They're not likely to come knocking again anytime soon, and you can consider it a relatively painless learning experience.

Audit Readiness and Your Profitability

Daryl, would you like to add a few words?

Daryl Ullman: Absolutely. I want to emphasise that the risk of an audit, while always present, is relatively low. It's unlikely an audit will suddenly appear on your doorstep tomorrow. Microsoft typically conducts audits on a recurring basis every three to four years, and some of our clients have never been audited.

So, the risk isn't uniform across the board. But even with that said, I want to be clear about this because we believe in transparent communication; our business isn't solely focused on audit protection. It's just one of the services we offer. Our core mission is to empower businesses to grow and thrive.

As Alex highlighted, part of that involves being prepared for an audit. Again, the risk is minimal. However, there's an added benefit to audit readiness: it helps you get your house in order. This goes beyond just compliance, which is a natural consequence of doing business well.

Compliance isn't the end goal. The ultimate objective is to boost profitability. By having your house in order, you're in a prime position to identify untapped opportunities, like unbilled Microsoft software, that you're providing but not charging for. We see this repeatedly during audits, where we analyse the entire process, from reporting and billing to invoicing. We often discover that software being used, or even reported to Microsoft, isn't being accurately billed or invoiced to the end customer. This means you're missing out on valuable revenue.

So, to recap, yes, there's always a risk of an audit, but it's minimal. Yes, you still need to be prepared because that's the cost of good governance and adhering to the terms of your contract.

However, the real payoff here is the ability to uncover additional revenue opportunities for your business. If that's not a compelling reason to implement proper governance, I don't know what is. So, from my perspective, what I hope you take away from this is that while best practices are undoubtedly important, and everything Alex has shared is invaluable, this isn't just about preparing for an audit.

It's about making an immediate, tangible impact on your business starting tomorrow. This is how you, as business professionals, can genuinely make a difference within your organisation.

By implementing these practices, you're not just ensuring operational excellence. You're also driving revenue growth; ultimately, that's the bottom line for any company. That's my two cents on this excellent presentation. Alex, thank you for inviting me to share my perspective.

Alexander Golev: Thanks, Daryl. For those who don't know, Daryl's my business partner and co-founder at SAMexpert, where we manage Microsoft relationships for our clients. We don't sell licenses, which allows us to provide unbiased advice.

We don't rely on Microsoft. We don't care what they're selling; we care about what you're spending. We're all about your bottom line and your top line, too.

Speaking of which, make sure to follow Daryl if you haven't already done so. He runs his own events; next week, he's got another one on Wednesday. Daryl's our Chief Negotiation Officer. He's written a book called "Negotiating with Microsoft," he even has his own Negotiation Masterclass. Here at SAMexpert, he's our last line of defence against Microsoft in audits. I handle the audit preparation and defence while he steps in to negotiate the outcomes. He's a fascinating speaker, so I highly recommend checking out his events.

Upcoming SAMexpert Events

We've got another SPLA event coming up that'll kick off a whole new series. This time, we won't be dwelling on audits. Instead, we'll focus on licensing design, profitability, and all the ins and outs of different services like SaaS and IaaS. We'll cover the hurdles, the various licensing models, and the pros and cons of switching to CSP hosting or sticking with SPLA.

If you're more involved in the day-to-day management of your licensing, this series will be particularly relevant to you. I promise it'll be much more interesting than the sometimes daunting topic of audits. I hope to see you there, and thanks again for joining us today. As always, I hope you found this useful. Don't forget that if you want our SPLA audit readiness checklist, drop us a line at ask@samexpert.com. I'll send it over along with a few words of advice.

Thanks again, and have a great day!