Audit evidence management — what to hand over, and what not to.

Evidence is the audit — not a preamble to it.

Software audits do not turn on legal arguments. They turn on what the vendor's scripts return, what your engineers volunteer in interviews, and how the contract is read against that data. Once the evidence is in vendor hands, the legal positions are mostly written into the corners. The implication for buyers: control the evidence phase tightly, or be prepared to negotiate from whatever it produces.

Audit teams at Oracle LMS, Microsoft SAM Engagement, SAP GLAS, and the equivalents at IBM and VMware all follow comparable methodologies. They request a defined set of artefacts — inventory exports, ULN evidence, user lists, deployment maps — and reconcile against contract entitlements. The reconciliation produces the Effective Licensing Position (ELP), which becomes the claim. Every deduction is evidence-derived; every offset is evidence-derived; every escalation is evidence-derived.

The four evidence categories

• Discovery output. Vendor-provided scripts run against your estate. Oracle LMS Collection Tool, SCCM exports, SAP USMM, Flexera or Snow exports.
• Self-attested data. Lists of users, named accounts, BYOL declarations, deployment summaries provided by your team.
• Contractual evidence. The signed contract, ordering documents, amendments, support renewals — the entitlements that frame the count.
• Interview and workshop output. Statements made by engineers and architects in walkthrough sessions, captured in vendor notes.

Narrow the scope before producing a single artefact.

The first script the vendor sends will request more than the contract entitles them to. This is not deception — it is standard practice, and over-scoping is rational on the auditor's side. The defence is to read the audit clause carefully and respond with a scoped data request reflecting only what the clause requires. Most audit clauses specify the systems in scope, the data formats, the timeline, and the named entity. All four are levers.

The four scope levers

1. Entity scope. The audit applies to the contracting entity. Subsidiaries acquired post-contract may or may not be in scope depending on assignment clauses.
2. System scope. Production and non-production may be separately treated. DR systems, test environments, and embedded software each carry contract-specific rules.
3. Time scope. Audits cover a defined period. Data older than the audit window should not be furnished.
4. Format scope. Vendors prefer scripts; contracts typically allow exports in equivalent formats from existing SAM tools.

The single-source-of-truth practice

All evidence flowing to the vendor should pass through one named coordinator on the buyer side. No engineer should respond to vendor data requests directly. No interview should be unaccompanied. Vendors learn quickly which estates have central control and which do not; the negotiation tone shifts accordingly.

Build the evidence in a form that survives challenge.

The buyer's evidence is at least as important as the vendor's. Effective Licensing Position rebuttals turn on whether the buyer can demonstrate alternative deployment counts, contractually permitted exclusions, and offsets the vendor would not surface unprompted. The evidence has to be reproducible, time-stamped, and prepared in a form the vendor cannot easily dismiss.

Reproducibility

Every evidence artefact should carry a documented derivation. If a deployment count comes from SCCM, the SCCM query, run time, and source database should be recorded. If a user count comes from Active Directory, the LDAP filter and group structure should be recorded. Vendors challenge unsupported numbers; they accept reproducible ones. Reproducible, contract-tied evidence is the backbone of any buyer-side software license audit defense.

Time-stamping and versioning

Evidence runs change. A user count at week 4 of the audit is not the same as at week 8. Each run should be archived, version-tagged, and not overwritten. If the vendor challenges a number, the buyer should be able to produce the underlying export with full metadata.

Privileged review

Evidence prepared under legal privilege protects the buyer from later use. Engaging counsel and structuring the evidence-collection effort as legal-led can preserve privilege for sensitive artefacts (internal memos, valuation models, escalation correspondence). The mechanics vary by jurisdiction; the discipline is worth the time.

Five evidence mistakes that drive claims up.

1. Volunteering scope. Engineers volunteer information about systems outside the audit clause. Once in vendor hands, it is in scope.
2. Running unverified scripts. Vendor scripts can pull data beyond what the contract allows. Each script should be reviewed before execution.
3. Conceding interpretations. Statements like 'we count it that way too' bind the buyer to interpretations they have not validated against the contract.
4. Missing offsets. Unused entitlements, shelfware, and contractual exemptions are buyer-side evidence the vendor will not surface.
5. Single-source vendor data. Letting the vendor's discovery output stand as the only data point removes the buyer's ability to challenge.

Three actions to take now

First, name a single audit coordinator with authority to gate every evidence response. Second, build a contract-driven scope document before running any vendor script. Third, version and archive every evidence artefact under legal privilege where possible. The Vendor Audit Defence Handbook walks through each step.