Documenting Multi Tenant Isolation for Hosters

A hoster runs many customers on shared infrastructure, and the platform is designed so that one customer cannot reach another customer's data or workloads. That isolation is usually built and defended as a security and privacy control. In a SPLA audit it becomes something else: the evidence that decides how many users should be counted against each licensed product. If you cannot show where one tenant ends and the next begins, an auditor is free to assume that more users could reach a licensed workload than actually could, and a wider reachable population means a higher count, higher back fees, and a higher penalty. Documenting multi tenant isolation is how you take that assumption away from the auditor and keep the count tied to reality.

Why isolation is a licensing question

SPLA is pay as you consume, and hosters report Subscriber Access License counts, the SAL, or processor counts each month under the Services Provider Use Rights, the SPUR. A Subscriber Access License is owed for each user who has access to a licensed product. The phrase that matters is has access. Not used it once, not is billed for it, but could reach it. In a single tenant world that question is simple, because the population that can reach a workload is the one customer it belongs to. In a multi tenant world the question is only as clear as your isolation. If a licensed product sits on shared infrastructure and your boundaries are loose or undocumented, the population that arguably has access can be far larger than the population that genuinely does, and the auditor will count the larger one unless you can prove otherwise.

How undocumented boundaries inflate the count

Consider a shared environment where a licensed workload is deployed for one customer but lives on infrastructure that also serves several others. Technically, the workload is isolated to its customer. On paper, if that isolation is not documented, an auditor reconstructing the estate sees a licensed product on shared infrastructure and a much larger total user base across all tenants. With no boundary record to consult, the conservative reconstruction counts the wider population as having potential access. The hoster knows the real number is small. Proving it after the fact, three years later, from logs that were never organized around tenancy, is the hard part. The work that would have taken minutes a month at the time becomes a forensic exercise under audit pressure, and any part of it you cannot prove resolves against you.

What documentation an auditor will accept

Documenting isolation does not mean writing an essay about your architecture. It means producing records that let an auditor verify, for any month in the 36 month lookback, exactly which users could reach which licensed workloads and why no one outside that set could. The records that carry weight are concrete and contemporaneous:

• A tenancy map that ties each licensed workload to the single customer or defined group it serves
• The technical controls that enforce the boundary, network segmentation, access policies, and identity scoping, described per workload
• Evidence that the controls were in force in each reported month, not just at audit time
• The reachable user population for each licensed product, derived from the boundary, reconciled to the SAL reported
• A change log showing when boundaries moved, so a customer added or removed is reflected in the right month

The unifying principle is that the boundary must be provable for the past, not just demonstrable for the present. An auditor reviewing a 36 month lookback is not interested in how your platform is configured today. They are interested in how it was configured in the month under review, and whether the users you counted that month match the users who could reach the workload that month.

A worked illustration of the boundary effect

The figures below are indicative and chosen only to show the shape of the effect, not to quote any real outcome. Picture one licensed product on shared infrastructure with several tenants present.

Indicative illustration of how a documented boundary collapses an assumed count to the proven one, not a quoted outcome.

The gap between the two columns is pure documentation. The real number of users who could reach the workload is the same in both, but only the documented column can prove it. The undocumented column is the cost of leaving isolation implicit, and on a single product on shared infrastructure it can dwarf any genuine compliance gap elsewhere in the estate.

Keeping the boundary current as the estate changes

A boundary document is only useful if it tracks reality month by month. Hosting estates change constantly: customers are onboarded, workloads migrate, environments are consolidated, and tenants leave. Each of these moves the population that can reach a licensed product, and each should be reflected in the boundary record for the month it happened. The discipline is to treat the tenancy map as a living record maintained as part of normal operations, not a document refreshed once a year. When a customer churns, the boundary record should show their access removed in that month, so the SAL count drops in step and you are not counting and paying for a customer who left, the over reporting failure covered in over reporting versus under reporting in SPLA. When a new workload is stood up on shared infrastructure, its boundary should be documented from day one, so it never enters the audit as an unexplained presence on a shared host.

Where isolation fits in the wider defense

Documented isolation is one of the pillars of reporting discipline, and it works with the others rather than alone. The reachable population it defines is reconciled against the sealed daily authentication counts described in sealing daily authentication counts, so the users who could reach a workload and the users who actually authenticated are both evidenced and consistent. Together with customer mapping and version mapping, isolation forms the monthly reconciliation that lets a hoster meet a Big Four auditor with records rather than reconstruction. The full posture is set out in the SPLA Audit Defense Guide, which ties each pillar to the way the audit is actually run.

The next step

If your multi tenant boundaries are real in your architecture but not documented in a way an auditor could verify for past months, that gap is exposure waiting to be counted against you. A Strategy Call will pressure test how your isolation would read to a Big Four auditor across a 36 month lookback, and show you where the count could be inflated before it is. We work on a Fixed Fee from $18,000 or on Gainshare, a share of verified savings or avoided penalty with zero retainer and no risk to you, and our guarantee stands behind both: we reduce your exposure, or we reimburse our service fee.

If you would rather not face that alone, we defend the full 36 month lookback through our SPLA audit defense work.