At Livingstone, we are increasingly approached by service providers – systems integrators, hosting providers or any other organizations providing managed services to their end-user customers – to help them navigate Microsoft Services Provider Licensing Agreement (SPLA) audits.
On the surface, SPLA audits follow a similar process to standard vendor audits. Microsoft will issue an audit letter, data is collected and analyzed, before an Effective Licensing Position (ELP) is established and signed-off by both parties. However, there are some key differences – or pitfalls – to navigate, particularly when it comes to the audit timeframe and scope, as well as how licensing liability is shared between the service provider and its customers.
These three factors introduce new risk factors to the audit process, and could leave service providers facing bigger penalties and back-dated payments if not properly addressed from the outset.
Here are the top three areas to consider when trying to mitigate commercial risk from the SPLA audit process:
#1: The audit timeframe
A regular compliance audit is a single-point-in-time exercise. The customer organization provides a snapshot of usage at a specified moment, which is then compared to its licensing entitlement.
SPLA audits don’t follow this process. They look at usage across an entire ‘audit window’, and the service provider is required to report on consumption for each and every month within the stipulated period. This means that, in addition to providing comprehensive data relating to usage at the time of the audit, a service provider must also produce historical information.
Problems begin to arise when service providers haven’t kept data on past usage. These audits can cover substantial periods of time; as long as seven years or more. Without adequate documentation covering this entire timespan, commercial risks can soon mount up.
Connected to this is the way Microsoft approaches SPLA audits. Unless the service provider can produce comprehensive data to prove prior usage levels, Microsoft may presume that utilization rates at the time of audit were at a similar level throughout the duration of the audit window. A service provider which has recently spun up ten new virtual machines to support new users, will need documented proof of when this change took place. The traditional audit excuses of ‘it was just temporary’ won’t wash, not without solid proof to back it up.
On a similar note, it is imperative not to destroy records relating to decommissioned equipment. Service providers should always take a snapshot of what was used and when in order to provide a ‘quibble-free’ audit trail of information to Microsoft.
Another item to bear in mind is that Microsoft contracts state that it is entitled to conduct a SPLA audit for two years after the contract is terminated. Service providers which think they’re audit-proof because their contracts have expired could be in for a nasty surprise.
#2: The technical scope
As with any audit, it’s imperative to provide accurate data relating to all the locations, clusters, servers, assets and domains covered in the audit scope. However, with SPLAs, there’s a tendency for service providers to either overstate or understate usage; neither of which is a good idea.
Service providers sometimes hand over information relating to management clusters, disaster recovery sites, or more, which is out-of-scope of the audit. They presume that Microsoft will disregard this information if, at a later date, they explain it’s not applicable. Microsoft might well be convinced, but this may take considerable time and effort to prove. Of course, once this information is disclosed it can’t be ‘unseen’ so could trigger further action.
On the flipside, some service providers will be reluctant to report on usage relating to certain users, applications or workloads, citing security or regulatory concerns, particularly as this information relates to their customers’ – rather than their own – service utilization. Any gaps in the data will raise red flags so Livingstone’s advice is always to obfuscate – rather than omit – this data.
#3: Working out who’s accountable
Working out which party is liable for licensing and compliance – the service provider which is hosting the services or the customer which is using them – isn’t always straightforward.
The good news is Microsoft agreements make it relatively simple for service providers to indemnify themselves if there is a dispute, while they can also sign a license mobility addendum in order to assign their customers’ existing on-prem licenses to their own virtual machines (aka ‘Bring Your Own License’).
Without the requisite paperwork, things can get considerably messier. That’s because, under a SPLA, every piece of Microsoft software deployed on the service provider’s infrastructure will be considered its own responsibility, irrespective of whether it supports them all. While a service provider may argue its machines only hosts services at an OS level, if its customer is using the same machines to host Office, the service provider could end up liable.
In our experience, approximately 90 percent of initial SPLA audit shortfalls relate to unsupported licenses, some of which service providers don’t even know about.
Speak to an expert
For more information on how to alleviate these problems and successfully navigate a SPLA audit, please contact one of our specialist audit experts.
ABOUT THE AUTHOR
The Author: Alexander Golev, Service Integration Consultant
Alex has over 15 years’ experience in Software Asset Management and has worked with clients around the globe, from small businesses to multinational corporations. He is the author of more than 10 SAM online training and webcasts and has delivered training worldwide along with presenting at a number of industry events. Alex has in-depth vendor experience with Microsoft (including SPLA), Citrix, Adobe, and lead consultant experience in Oracle, SAP, IBM, VMware and Veritas.