Summary
In SPLA audits, a common pitfall is misinterpreting the audit scope, often leading to the erroneous inclusion of non-hosting environments as SPLA debt.
Or, in simple words:
You accidentally provide the auditor data from a non-hosting environment,
They include it in the calculation,
The result is that your "SPLA debt" to Microsoft is unreasonably inflated.
Can you correct it later? We have seen tens of audits when it was easy. We have also seen cases when the auditor would stubbornly resist it. Here is a quote from a frustrated provider:
"We accidentally submitted a non-hosting cluster, and the auditor counted it as a SPLA debt. Now they don't want to de-scope it."
Never underestimate the critical importance of precision in data submission during audits.
Understanding the Auditor's Perspective
Auditors, adhering to their protocols, may stubbornly classify non-hosting clusters within SPLA scope, even when such inclusion is incorrect. If anything is unclear or ambiguous, their standard approach is to assume the worst case. The source of the challenge here lies not in the auditor's approach but in the initial data submission.
Providers frequently make the error of oversharing, propelled by a lack of internal clarity on what constitutes their SPLA services. It is especially prevalent when technical personnel, without a nuanced understanding of SPLA scope, are the primary points of contact for auditors.
The Essence of SPLA Scope
As delineated in Microsoft's Audit Notice Letter, SPLA audits are intended to assess only those services licensed under SPLA or Bring Your Own License (BYOL) arrangements. No extraneous data should find its way into the audit scope.
However, when providers struggle with demarcating their SPLA services internally, they inadvertently provide auditors with excessive information, leading to complications such as the wrongful inclusion of internal use environments in the SPLA audit.
Strategy for Resolution
In scenarios where auditors remain unyielding, the best course of action is persistent pushback, ideally underpinned by solid evidence. This approach is predicated on the certainty that the disputed environment is indeed outside the SPLA scope.
It is essential to establish that the environment in question is licensed under enterprise agreements and is unrelated to the internal use of SPLA or any hosting services provided.
Involve Microsoft: In cases of auditor inflexibility, escalating the matter to Microsoft can help.
Assertive Communication: Maintaining a firm stance in communications with auditors is vital. Clearly articulate the reasons why the non-hosting cluster is outside the SPLA scope, providing evidence and documentation to support your claim.
Internal Audits and Preparation: To prevent such scenarios, conduct thorough internal audits and preparations before engaging with external auditors. This includes defining and documenting the scope of SPLA services and ensuring that only relevant data is shared.
Legal and Compliance Expertise: Engage with legal and compliance experts who understand the nuances of SPLA agreements and can provide strategic advice on dealing with auditors and Microsoft.
You Can Do It
Remember, effective communication and thorough preparation are your best tools in ensuring that your SPLA audits are fair, accurate, and reflective of your actual service scope.
As always, if you want to discuss your SPLA Audit questions, we are just one message away: