The question of what data to share in a SAM engagement is really the question of how much of the outcome you decide in advance. Because a SAM engagement is voluntary and sales led, you set the terms of access, and the data you provide becomes the raw material the review uses to build its findings. Share narrowly and deliberately, and the findings stay anchored to a scope you control. Share broadly and reflexively, and you hand the sales side the material to build whatever case the data will support.
This article sets out how to think about data in a SAM engagement: what the review genuinely needs, what it asks for that you are not obliged to give, and how to keep every release deliberate. For the broader method, read the SAM engagement playbook.
Start from the nature of the engagement
A SAM engagement is not a formal audit. A formal audit runs through a third party accounting firm under the MBSA audit clause, with defined authority to request deployment records and usage data. A self verification is a contractual demand you cannot decline. A SAM engagement is neither. It is voluntary, sales led, and presented as a free optimization. That status is the whole basis for your control over data. There is no clause compelling broad disclosure, so disclosure becomes a choice you make rather than an obligation you meet.
In a voluntary engagement, every byte you share is a decision. Treat it as one.
Why the data lens is not neutral
Microsoft uses its own counting methodology and its own data drawn from Azure, Microsoft 365, and management tooling. The way your estate is counted is not fixed by the raw numbers. It is shaped by which data is in view and how it is read. A sales led review reads ambiguous use in the direction that supports a purchase, so the more raw material it holds, the more room there is to assemble a gap. This is why a SAM tool output is not audit defense. The output reflects the methodology and the inputs, and both can favor the vendor.
A simple way to classify a request
Before you respond to any data request, sort it into one of three categories. The category, not the urgency of the ask, should decide your response.
| Category | Examples | Default stance |
|---|---|---|
| Needed for the agreed scope | Entitlement records for the products under review | Provide, in a form you have verified |
| Broad or open ended | Full management tooling exports across the estate | Narrow to scope, or decline |
| Better held until later | Raw telemetry that invites reinterpretation | Withhold unless and until genuinely required |
Lead with entitlement, not deployment
Your strongest data is your entitlement record, the licenses you hold and the rights attached to them. That is the data that reduces a count rather than inflating it. Where deployment data tends to grow the picture of what you use, entitlement data establishes what you are already allowed to use. Prepare and verify your entitlement evidence first, and lead with it, so the conversation starts from what you own rather than from what you might owe.
- Agreements and amendments that define your rights
- Purchase and reseller records across the relevant period
- Rights that reduce count, such as downgrade, reassignment, and prior true up credits
- Any previously agreed positions that should carry forward
Be cautious with raw deployment exports
The requests that deserve the most caution are the broad deployment and telemetry exports: full pulls from management tooling, raw Azure and Microsoft 365 usage data, and anything that captures activity without context. These exports are where ambiguity lives, and ambiguity is what a sales led review converts into a gap. You are not obliged to provide them in a voluntary engagement, and where you do provide deployment data, it should be scoped, contextualized, and reconciled against entitlement before it leaves your hands rather than after.
Context is yours to add before you send the data. After you send it, the interpretation is theirs.
Keep a release log
Whatever you decide to share, record it. A simple release log that captures each item, the date, the approver, and the reasoning keeps your disclosures deliberate and gives you a clear account of what the review was actually based on. If the engagement ever escalates toward a self verification or a formal audit, that log is the record of what has and has not already been disclosed, and it stops the same data being reinterpreted without your knowledge.
The bottom line on data
Sharing data in a SAM engagement is not about secrecy. It is about proportion and sequence. Provide what the agreed scope genuinely needs, lead with the entitlement evidence that works in your favor, hold back the broad exports that invite reinterpretation, and log every release. Because the engagement is voluntary, all of this is within your control, and that control is the difference between a review that reflects your real position and one that reflects the vendor's preferred reading of it.
A buyer side advisor decides these questions with you, request by request. We verify your entitlement first, scope each release to your interest, and keep the record clean in case the engagement escalates. For the complete method, download the SAM engagement playbook.
If you would rather not face that alone, our SAM engagement response team runs your internal assessment before Microsoft sees a single number.