The SPLA Data Request and How to Handle It

The data request is the heart of a SPLA audit. What you provide, how you scope it, and how you document it shape every number that follows. Handled with discipline, the request becomes a controlled exchange. Handled loosely, it becomes a fishing expedition.

What the auditor is allowed to ask for

A SPLA audit is conducted by a Big Four firm under the MBSA audit clause, acting as an independent third party with broad authority to request deployment records, server configuration data, customer contracts, and usage logs. Broad authority is not unlimited authority. The request must sit inside the clause and the agreed scope, and it covers the 36 month lookback, not an open ended history. Your first task is to read the request against the clause and confirm that every item asked for is actually within it.

How to handle the request, step by step

1. Scope it against the clauseMap each requested item to the agreement. Flag anything that reaches beyond the stated scope or the 36 month window and address it in writing before providing it.
2. Provide through one channelAll data flows through a single owner. No team responds directly to the auditor. This keeps the record consistent and prevents accidental over disclosure.
3. Reconstruct before you submitFor each month in the lookback, rebuild your SAL or processor counts from primary sources, sealed daily authentication counts, customer mapping, and version mapping. Submit verified figures, not estimates.
4. Provide what is asked, not moreAnswer the specific item. Do not attach unrequested logs, internal spreadsheets, or context that widens the picture.
5. Document every exchangeKeep a written log of what was requested, what was provided, and when. The record protects you if a finding later overstates consumption.

The structural defense lives in your records

The reason a disciplined data response works is that the structural defense in SPLA is reporting discipline. The records that answer the request are the same records that prove compliance, monthly SAL reports submitted on time for every month, sealed daily authentication counts, customer mapping for each reported SAL block, product version mapping, and documented multi tenant isolation. When these exist and are clean, the data request is a matter of presentation. When they are thin, the request exposes the gap, which is why reconstruction comes before submission.

What to keep inside the clause

• Live access to hypervisors, authentication systems, or management consoles, which lets the auditor count on their terms
• Customer contracts beyond those needed to verify the reported SAL blocks in scope
• Raw logs for periods outside the 36 month lookback
• Internal estimates or draft figures that were never validated
• Commentary speculating about past under reporting before reconstruction is complete

A worked reconciliation view

The figures are indicative and show the shape of a monthly reconciliation, not real data.

Month	Reported SAL	Reconstructed SAL	Note
Month 06	1,200	1,200	Matches, on time
Month 14	1,350	1,310	Over reported, recover margin
Month 22	1,400	1,470	Under reported, quantify and address

Reconstructing each month this way turns the data request from a threat into a controlled accounting exercise, and it surfaces over reporting you can recover as well as gaps you must manage.

The next step

The data request rewards preparation and punishes improvisation. Our Hoster Readiness Workbook walks through the records that answer it cleanly, and the related articles below cover the opening hours and the settlement that follows. Download the workbook and build the reconstruction before the request lands.

Related reading

When the numbers start to look serious, our SPLA audit defense team challenges the counting before back fees are set.