Microsoft SPLA Audit Defense

What a Microsoft SPLA audit is — and is not

A Microsoft SPLA audit is a contractually-permitted examination of your Services Provider License Agreement (SPLA) compliance. The scope is your provision of Microsoft software to your customers as part of a hosted service — typically managed hosting, dedicated hosting, multi-tenant SaaS, or specialized vertical hosting (healthcare ISVs, financial-services hosters, MSPs).

What it is not: it is not the same as a Microsoft EA audit of your internal Microsoft usage (that is governed by your EA, MPSA, or other commercial construct). It is not a Microsoft Verification engagement scoped to dual-use rights only. It is not a SAM engagement, although Microsoft will sometimes attempt to fold a "deployment review" into a SPLA conversation; resist that scope creep.

The contractual basis for the audit is the SPLA itself plus the Microsoft Product Terms / Services Provider Use Rights (SPUR). The auditor — typically Deloitte, KPMG, EY, or Microsoft's internal LCA function — works to a defined scope letter. Demand the scope letter at first contact.

What triggers a SPLA audit

SPLA audits are triggered by a combination of risk-based heuristics and rotational scheduling. Five common triggers we see in our hosting-client work:

1. Inconsistent monthly usage reports. A pattern of report-volume that does not correlate with publicly observable business activity (customer announcements, growth disclosures, infrastructure expansion).
2. Customer growth without SPLA growth. Public customer wins or hosted-environment expansion that does not appear in subsequent month-over-month reports.
3. M&A activity. Acquisitions or divestitures involving hosted environments routinely trigger entitlement-transition audits.
4. Reseller-driven escalation. Your SPLA reseller may flag inconsistencies during the monthly reporting process; some of those flow to Microsoft as audit candidates.
5. Rotational schedule. Hosters above ~$500K annual SPLA spend can expect an audit cycle every 24-36 months independent of any specific trigger.

SAL vs SAL-for-SA: the classification trap

The most common SPLA audit finding is misclassification between SAL (the standard subscriber access license) and SAL-for-SA (the variant that accommodates customer-owned Software Assurance entitlements). The two are not interchangeable, and the contractual conditions for SAL-for-SA are specific.

SAL is the standard model: you report the unique end users accessing the hosted software each month and pay the per-user fee. The customer does not bring their own entitlement; you provide the license through your SPLA.

SAL-for-SA permits a customer with qualifying underlying Software Assurance (typically on a covered SKU through their own EA or MPSA) to access your hosted environment under their own license rather than a SPLA-provided license. The conditions are exact: the customer's SA must be live, the SA must cover the relevant SKU and version, the contractual relationship between you and the customer must document the arrangement, and the SA-eligible scope must be tracked separately.

The audit failure mode is treating customers as SAL-for-SA without verifiable SA evidence. Microsoft audit teams routinely reclassify SAL-for-SA entries as standard SAL, with backdated true-up exposure across the reporting period.

Listed-provider obligations and authorized-hoster rules

Historically, certain Microsoft SKUs — Windows desktop OS, Office desktop applications, and select other titles — required hosters to be on the Microsoft "listed provider" / "authorized hoster" program with explicit Microsoft authorization. The 2022 hosting changes restructured aspects of this construct, and 2025-2026 has seen continued evolution.

The practical points for SPLA audit defense:

• Validate your listed-provider status against your current SKU portfolio. SKUs you hosted three years ago may not require listing today; SKUs you host today may.
• Document the customer-relationship test for any "outsourcing" arrangements — Microsoft has tightened how it interprets outsourcing rights and what constitutes dedicated infrastructure.
• For specialized hosting categories (healthcare, regulated industries) the listed-provider conversation has additional layers; do not assume general listed-provider authorization extends to specialty SKUs without explicit confirmation.

Monthly reporting: the highest-frequency failure mode

The monthly SPLA usage report is the single most-audited artifact, and the highest-frequency source of findings. Five reporting failure modes to address:

1. Stale usage-collection tooling. Hosting environments evolve; reporting tooling does not always keep up. Customers shift from VM to container, from dedicated to multi-tenant, from one product to another. Collection gaps surface as under-reporting.
2. Unique-user counting errors. SPLA reports unique users per month; double-counting across customer tenancies or under-counting at access-tier boundaries are both common.
3. Zero-use months. A month with zero reported use of a SKU that you have hosted historically triggers auditor attention — they will ask why.
4. Late or missed filings. SPLA contracts require monthly reporting on a defined cadence. Late filings create gaps and process-compliance findings independent of the substantive use.
5. End-of-year reconciliation gaps. Annual true-ups that materially differ from the monthly run-rate produce audit interest by themselves.

The document base you must have ready

At first audit notification, immediately pull the document base together. The audit will request these in some form; having them ready compresses the audit timeline and limits scope expansion:

• 24 months of monthly SPLA usage reports filed to your reseller.
• Customer contracts demonstrating the hosting relationship for each customer in your SPLA-reported set.
• SA evidence for every SAL-for-SA customer (their EA or MPSA enrollment number and the SKU-specific SA coverage proof).
• Infrastructure inventories tied to the reported use — VMs, hosts, customer-tenancy boundaries, multi-tenant systems.
• Per-SKU provisioning logs for the audited SKUs (Windows Server external connector usage, SQL Server core licensing assignments, RDS CAL provisioning records).
• Authorized-hoster / listed-provider documentation for any SKUs that required it during the audit period.
• Change logs documenting any material customer or infrastructure transitions during the period.

SPLA audit response playbook

The defensive structure for a SPLA audit has six phases:

Phase 1 — Receipt and scoping. When you receive the audit notification, do not engage substantively until you have the auditor's scope letter, the named SKUs in scope, the named audit period, and the named audit firm. Identify the auditor as Deloitte, KPMG, EY, or Microsoft LCA — each operates with different methodologies and tolerances. Engage independent audit defense counsel at this phase, not later.

Phase 2 — Internal readiness. Pull the document base. Run a parallel internal audit against the reported use to identify likely findings before the auditor does. The internal findings inform your negotiation posture.

Phase 3 — Information request response. The auditor will send a comprehensive information request. Respond completely, accurately, and only to the requested scope. Do not volunteer adjacent data — every additional artifact opens scope.

Phase 4 — Preliminary findings review. The auditor produces a preliminary findings report. Challenge it line by line. SAL-for-SA reclassifications are recoverable with SA evidence. Listed-provider questions are resolvable with documentation. Reporting gaps may be reducible with retroactive evidence.

Phase 5 — Negotiation and settlement. The final number is rarely the preliminary number. Settlement negotiation routinely produces 30-60% reduction on the preliminary finding with strong evidence and an independent advisor in the room. Our Microsoft Audit Defense service handles this regularly.

Phase 6 — Forward remediation. Any settled findings drive forward remediation — reporting-tool fixes, contract template updates, SAL/SAL-for-SA classification reviews. The remediation work is also the prevention work for the next audit cycle.

Common findings and how to negotiate them down

Year-round SPLA hygiene: how to prevent the next audit

The best SPLA audit defense is preventing the next audit from finding anything. Six year-round practices:

1. Quarterly internal SPLA review. Reconcile your reporting against actual infrastructure and customer access logs.
2. SA-evidence database. For every SAL-for-SA customer, maintain current evidence of their qualifying SA in a single accessible place.
3. SKU-by-SKU listed-provider audit. Annually validate which SKUs you host against current listed-provider rules.
4. Customer contract templates. Update to clearly document the hosting-relationship boundaries Microsoft tests on.
5. Reporting-tool maintenance. Treat SPLA reporting tooling as critical infrastructure; ensure customer-tenancy changes are reflected within one reporting cycle.
6. Pre-audit defense readiness. Maintain the document base in a state where any auditor request can be fulfilled within 5 business days.

Major 2026 changes affecting Microsoft SPLA audit

Three named 2026 changes:

1. CSP grace-period closing. Microsoft's CSP commercial restructuring has tightened the boundary between SPLA hosting and CSP reselling. Hosters that drift across the boundary are surfacing in audit findings at higher rates.

2. AI-workload hosting clarifications. SPLA rights for hosted AI workloads (Copilot extensions, custom agents, GPU-attached hosting) have evolved through 2025-2026; validate scope before assuming standard SPLA covers AI-attached hosting.

3. Microsoft Verification expansion. Verification activity has increased through 2026, including in adjacent areas that overlap SPLA (dual-use rights, hosting-vs-internal-use boundaries).

See our Microsoft Audit Defense guide for the broader audit-defense methodology that informs SPLA defense.