The IBM audit data request, and what you should never send first.
The data request is the most important moment in an IBM audit, and most companies hand over the wrong thing in the first week. What you send first sets the count IBM works from for the rest of the engagement. Send raw inventory and you have given away your position before building it.
What IBM actually asks for
After the notice and acknowledgement, IBM moves to the data request. It typically asks for a deployment inventory across the products in scope, output from a discovery tool, ILMT reports where sub capacity is claimed, virtualization details by host and cluster, and entitlement records. The request often arrives as a broad template that asks for far more than the audit needs, because a wider net surfaces more to count.
The data request stage usually runs four to six weeks. That window exists for a reason. It is time to validate what you send, not a deadline to dump everything you have.
Why the first send matters most
IBM builds its compliance position from the data you provide. The first complete dataset it receives becomes the anchor. If that dataset is raw, unscoped discovery output, IBM will read every ambiguity its own way: full capacity where sub capacity is not yet evidenced, the highest processor value unit per core where the hardware is unclear, and every install counted as production whether or not it runs.
Once that anchor is set, you spend the rest of the engagement arguing the count back down. It is far stronger to send a scoped, reconciled response that already reflects a defensible position.
What you should never send first
- Raw discovery exports. Unfiltered tool output lists everything detected, including decommissioned hosts, test copies and software you are not even using.
- Full inventory dumps. A complete estate export hands IBM scope you were never obligated to volunteer for the products in question.
- Unvalidated ILMT reports. ILMT miscategorizes installs by default. Sending its output before correction can manufacture findings that are not real.
- Internal emails and analysis. Commentary about known gaps or risks is not part of the data request and should never travel with it.
What to do instead
Acknowledge the request and agree a realistic timeline. Then build your own position before you respond. Recount processor value units against the correct tables, validate sub capacity against corrected ILMT data, map deployments to entitlements, and scope the response to what the audit legitimately covers. The data that leaves your network should be curated, validated and defensible, which is the Contain step of how we work: nothing goes to IBM until it is scoped and ready.
The data request is not an administrative task, it is the opening move of the negotiation. Send first, send raw, and you concede the count. Scope it, reconcile it, then respond, and you hold the line from the start.
The letter just landed?
Our Audit Defense engagement runs the Contain step for you: we scope and curate every byte before it reaches IBM, then build your position first. We mobilize within 48 hours of your audit notice.
See Audit Defense →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.