Quick recap:

In the last blog, we looked at why assigning a central contact person can make or break your IBM audit strategy. A single point of coordination prevents miscommunication, keeps audit activities organised, and reduces the risk of unvalidated data slipping through the cracks.

But having the right person in place is just the beginning.

Once the auditor starts sending questionnaires and data requests, the real scrutiny begins. This is where audits can quietly escalate—unless you understand what is being asked, and why.

What IBM Audit Data Requests Are Really Asking

Once IBM has initiated an audit and scope has been defined, you’ll start to receive detailed data requests. These might look like standard templates or spreadsheets but make no mistake—how you interpret and respond to these requests can shape the outcome of the audit.

Let’s break down what’s really happening—and how you can stay in control.

Why Auditors Request Data the Way They Do

The IBM audit clause obliges customers to “cooperate” with the audit—but it doesn’t define exactly what data you must share. That’s where discretion and strategy come into play.

Auditors aim to build a clear view of your license compliance status. But to do so, they may cast a wide net—asking for all kinds of data points, from server configurations and user access logs to custom deployment contexts.

This is your opportunity to shape the narrative.

✅ You can propose alternative data sources if they provide the same level of insight.

✅ You can ask: “What is the purpose of this request?”

✅ You can provide explanations early—before discrepancies turn into dollar amounts.

Not Every Question Is Created Equal

Many IBM products are accompanied by standardised audit questionnaires. These often assume worst-case licensing scenarios unless proven otherwise. But that doesn’t mean every question is applicable.

For example:

• You may be asked about installations in “Cold” or “Warm” standby mode—these may be exempt from license fees if correctly configured.
• You may be asked for deployment logs that don’t apply to your environment.
• You may be queried about historical data that’s already been accounted for in previous audits.

👉 Always assess the relevance of each request. Don’t be afraid to challenge vague or unnecessary items—politely, but firmly.

Leverage Your Own Internal Compliance Work

Have you recently performed an internal compliance assessment? That’s gold dust during an IBM audit.

Use your own data as a benchmark:

📌 Compare it with the auditor’s request list
📌 Highlight any inconsistencies or overreach
📌 Demonstrate that you’ve already verified certain data points

This positions your organisation as proactive—and may reduce unnecessary back-and-forth.

Provide Context Early—Not After the Fact

Auditors might flag what they perceive as anomalies: high user counts, duplicate installs, unusual configurations. But without context, these can lead to inflated findings.

Provide explanations upfront, such as:

• Legacy systems due for decommissioning
• Non-production environments
• Historical software that no longer exists
• Usage restrictions that limit license exposure

The earlier you explain these, the easier it is to resolve issues before they appear in a draft Effective License Position (ELP)—and before any financial value is assigned.

Final Thoughts

The key to handling IBM audit data requests is not blind compliance—it’s informed cooperation.

Every data request is an opportunity to clarify, challenge, or contextualise. By understanding what’s being asked and why, you gain more control over the audit narrative—and reduce the risk of costly surprises later on.

What is Next?

In our next blog, we’ll tackle the draft Effective License Position (ELP)—what it is, why it matters, and how to review it line by line before IBM sees a single figure.

Want to access the full guide on IBM license compliance audits? Download it here:

Your Email*

Consent*

By submitting this form the entered data will be handed over to and stored by us for contact purposes. You can review additional information about your data and rights in our Privacy Policy.*

Comments

This field is for validation purposes and should be left unchanged.

About the Author

Koen Dingjan, IBM Service Director

Koen is a seasoned expert in IBM licensing with nearly two decades of experience. A former Deloitte auditor, he has led over 60 IBM compliance reviews and developed an industry-recognised IBM compliance certification course. At ITAA, Koen helps clients manage IBM license compliance, defend against audits, and optimize license management strategies.