In a SPLA audit, the question that decides a large share of your exposure is deceptively simple: who consumed what. When a hoster runs shared infrastructure, the answer is rarely obvious from the raw data, and the auditor will resolve the ambiguity in the direction that grows the count. Multi tenant boundary documentation is how you resolve it first, on your own evidence, so that every unit of consumption is tied to the customer who actually used it.
This article sets out what multi tenant boundary documentation is, why it carries so much weight in a SPLA audit, and how to build a record that holds up across the 36 month lookback. For the wider method, read the SPLA audit defense guide.
Why boundaries decide the count
SPLA is pay as you consume, and hosters apply the SPUR and report SAL or processor counts each month. When tenants share infrastructure, consumption from many customers runs through the same servers, and the reported counts only make sense if each block can be traced back to a specific tenant. A Big Four firm conducts the audit under the MBSA audit clause with broad authority to request deployment records, server configuration data, customer contracts, and usage logs. When the boundary between tenants is undocumented, the auditor cannot see where one customer's use ends and another's begins, and unattributed consumption tends to be counted against you.
An undocumented boundary is read as the largest plausible boundary. Documentation is how you replace a guess with a fact.
What the auditor is actually testing
The auditor is testing whether your reported numbers can be tied to reality. For a multi tenant estate, that means three linked questions, and your documentation has to answer all three for every month under review.
- Which tenant consumed a given workload, so the SAL or processor count maps to a real customer
- Which product and version that tenant actually ran, so the count is reported at the right rate
- How the tenants were isolated, so use cannot be double counted across shared infrastructure
If your records answer these cleanly, the auditor reconciles to your evidence. If they do not, the auditor reconstructs the answers from incomplete data, and that reconstruction is rarely in your favor.
The documentation that holds up
Boundary documentation is not a single artifact. It is a connected set of records that together prove who used what, on which version, behind which boundary, for every month in scope. The table below sets out the core records and what each one defends against.
| Record | What it proves | What it defends against |
|---|---|---|
| Customer mapping | Each reported SAL block ties to a named customer | Unattributed consumption counted against you |
| Product version mapping | The version delivered matches what was reported | Consumption priced at the wrong, higher rate |
| Isolation evidence | Tenants were separated on shared infrastructure | The same use double counted across tenants |
| Sealed authentication counts | Daily access counts are contemporaneous and unaltered | Reconstructed counts that inflate the base |
Customer mapping for every SAL block
The foundation is customer mapping: every reported SAL block tied to a specific customer, with the contract and the usage record that support it. This is what turns a reported number into a defensible one. Without it, a block of access licenses is just a figure with no owner, and a figure with no owner is exactly the kind of ambiguity the auditor resolves upward. With it, the auditor can follow the block to a named customer, a signed contract, and a usage log, and there is nothing left to dispute.
Product version mapping
The same consumption can carry very different costs depending on the product version delivered, so product version mapping sits right next to customer mapping. Documenting which version each tenant actually ran, month by month, stops the auditor from assuming a higher edition than you delivered. This is a common and expensive source of overstatement, because in the absence of evidence the reconstruction defaults to the reading that grows the count, and an unmapped version is an open invitation to do exactly that.
Isolation evidence and sealed counts
The final layer is proof that the tenants were genuinely separated and that your counts are contemporaneous. Documented multi tenant isolation shows that shared infrastructure did not mean shared consumption, which is what prevents the same use being counted more than once across tenants. Sealed daily authentication counts, captured at the time and not reconstructed later, give the access numbers their evidentiary weight. Together they close the gap between what you reported and what you can prove, and that gap is where audit exposure lives.
A count you captured at the time defends itself. A count you rebuild under audit is an argument you may lose.
Build it monthly, not under audit
The hard truth is that this documentation has to exist before the audit, because there is only a short window to correct a reporting mistake and almost no way to recreate contemporaneous evidence after the fact. Boundary documentation built into the monthly reporting cycle is cheap and reliable. The same documentation reconstructed across 36 months under the pressure of an active audit is expensive, incomplete, and far less persuasive. The structural defense in SPLA is reporting discipline, and multi tenant boundary documentation is one of its load bearing parts.
Where this leaves you
Multi tenant boundary documentation is the difference between an audit reconciled to your evidence and an audit reconstructed from the auditor's assumptions. Map every SAL block to a customer, map every tenant to a product version, evidence the isolation, and seal the counts as you go. Do that across the months in scope and you walk into the audit with the answers already in hand, which is the strongest position a hoster can hold.
A buyer side advisor helps you build and defend that record. We map every reported SAL to a customer and a product version, document the isolation, and reconstruct the monthly base where the records need shoring up before an auditor sees them. If a SPLA audit is open or expected, the state of your boundary documentation will shape the result. Book a strategy call and we will assess it with you and plan the defense.
If this is live on your desk right now, we take over the process through our Microsoft audit defense engagement.