① Guide · audit response
A mainframe audit is built from the documents you hand over. Provide what is in scope, validate it before it leaves the building, and volunteer nothing beyond the contract. This guide lists the document requests auditors make, what to provide for each, and where pushing back on scope is not obstruction but discipline.
48 hour mobilization Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →Every document you provide becomes part of the auditor's calculation, so the response is as important as the underlying position. Three rules govern it. First, provide what is within the contractually defined scope of the audit, no more: data beyond the agreement is not owed, and handing it over invents findings that did not need to exist. Second, validate your own data before it leaves the building, because the figures you submit become the basis of the finding and any error in them tends to run against you. Third, respond precisely to what is asked rather than narrating your estate; over disclosure is the most common self inflicted wound in an audit. These rules are not evasion. They hold the audit to the terms both sides signed and ensure the conversation runs on accurate, in scope data.
Auditors work from a fairly standard set of requests. For each, what to provide and the buyer side caution:
| What is requested | What to provide | Buyer side caution |
|---|---|---|
| Hardware and machine details | In scope machine and model data | Confirm the audit clause covers the machines listed before sending |
| Operating system information | OS level for in scope systems | Limit to systems the agreement actually covers |
| Deployed software, edition and version | Accurate product, edition, and version inventory | Validate against entitlements first; edition mismatches drive findings |
| Environment per instance | Prod, test, DR designation as contracted | DR and non prod terms vary; check entitlement before classifying |
| Usage measurement data | SCRT reports for in scope sub capacity products | Confirm the measurement history is complete; gaps invite full capacity assumptions |
| Entitlement documents | Contracts, certificates, proof of entitlement | Assemble your own complete set first; you should know the position before they do |
| Requests beyond the agreement | Ask for the contractual basis or a scope amendment | Wider than the contract is not owed; push back rather than comply |
Directional and pattern level. On IBM sub capacity products the measurement tool is SCRT, expected monthly with history commonly kept around two years; other publishers use their own measurement and entitlement structures. Confirm the exact requirements and scope against your own audit clause and agreements.
The outcome of a mainframe audit is usually decided before any negotiation, in how the document requests were handled. The losing pattern is predictable: a team eager to look cooperative provides everything quickly, including data outside scope and measurement reports it has not validated, and the auditor builds findings from errors and over disclosure that a careful response would have avoided. Missing or incomplete measurement history is especially dangerous, because it commonly triggers a full capacity assumption that is far more expensive than the sub capacity entitlement. The winning pattern is the opposite: read the audit clause, define real scope, assemble and validate your own deployment, consumption, and entitlement data internally, correct your own errors first, and respond precisely and in scope. Where a genuine gap exists, you then negotiate it from knowledge. This is the core of our mainframe audit defense work. For the wider response, see how to respond to a mainframe software audit notice, the data detail in reading your SCRT report like a buyer, and the endgame in negotiating audit settlements on the mainframe.
Hardware and OS details, deployed software with edition and version, environment per instance, usage measurement such as SCRT reports, the licensing metric, and entitlement documents to reconcile against.
No. Provide what is in contractual scope, accurately. For requests beyond the agreement, ask for the basis or a formal scope amendment rather than complying. Over disclosure invents findings.
Because what you submit becomes the finding, and errors run against you. Reconcile internally and correct your own mistakes before the auditor sees the data, not after.
Read the audit clause and define real scope. Then assemble and validate your own deployment, consumption, and entitlement data before anything leaves the building.
The full response protocol from the first letter.
Validating the measurement data before it becomes a finding.