Multi-Vendor Software Audit Response Playbook: ITAM, Evidence and Defence

Why ITAM Is the Foundation of Every Audit Defence

Software audit defence is fundamentally an information management challenge. Every vendor that audits your organisation will bring its own measurement tool, its own interpretation of your licence agreement, and its own set of assumptions about your deployment posture. Your defence depends entirely on your ability to produce better, more accurate, and more granular information than the vendor's tool provides — and to present that information in a form that is contractually defensible and commercially credible.

The enterprise ITAM programme sits at the centre of that capability. But most ITAM programmes were designed for procurement governance and renewal management, not for adversarial audit defence. The licence metrics that matter most in a software audit — sub-capacity PVU calculations for IBM, Core Factor Table adjustments for Oracle, document interaction counts for SAP, or Azure Hybrid Benefit eligibility periods for Microsoft — require specialised data collection and analysis that standard Discovery and Software Asset Management tools do not perform natively.

Building multi-vendor software audit response capability means extending your ITAM programme to collect, store, and present evidence that is specific to each vendor's audit methodology, across every vendor simultaneously. This playbook provides the practical steps to achieve that capability, whether you are reacting to an audit already in progress or building proactive readiness before the audit notice arrives.

The Evidence Gap in Most Enterprise ITAM Programmes

Over 40 percent of organisations admit to accidental non-compliance due to hybrid licensing gaps — deployments in cloud, virtualised, and container environments where the standard ITAM discovery tool tracks software installation counts but cannot resolve the sub-capacity, partitioning, or deployment context that determines the correct licence metric. This evidence gap is the single largest vulnerability in most enterprise audit defence programmes.

For IBM, the gap manifests as ILMT data that was never collected, incorrectly configured, or collected inconsistently, leaving the organisation unable to assert sub-capacity licensing entitlement. Under IBM's rules, sub-capacity licensing is only valid if the IBM License Metric Tool (ILMT) has been correctly deployed and maintained throughout the entire audit period. Any gap in ILMT data coverage — even for a brief period — can void sub-capacity eligibility for all IBM products across the entire estate during that window, potentially converting a manageable compliance shortfall into a full-capacity liability that runs to millions of dollars.

For Oracle, the gap appears in virtualisation environments where the ITAM discovery data captures software installation but not the underlying physical host topology, NUMA node configuration, or VMware vMotion rules needed to support Oracle's partitioning requirements. For SAP, the gap appears in integration layer discovery: standard ITAM tools catalogue SAP software deployments but do not track the third-party systems generating document interactions that trigger SAP Digital Access charges.

Understanding the Five Major Vendor Audit Tools

Each major vendor uses specific tools and methodologies to measure your software deployment during an audit. Understanding what these tools measure, how they work, and where their outputs can be challenged is essential preparation for any multi-vendor audit response programme.

Oracle License Management Services (LMS) Scripts

Oracle LMS provides SQL scripts that query Oracle database instances, option components, and feature usage data. The scripts return licence usage data for all Oracle database products, options, and management packs detected on the scanned systems. Oracle's scripts do not discriminate between features that were used intentionally and those enabled by default — the output flags every feature that was ever enabled, regardless of whether it was actively used or commercially deployed.

The critical challenge with Oracle LMS scripts is that they report against the broadest possible licence metric. They will identify every server where an Oracle product is installed, and will apply full processor metric calculations unless you can demonstrate that a valid partitioning configuration exists. Hard partitioning (Oracle-approved partition types) can limit the processor count for licensing purposes. Soft partitioning (including VMware vSphere, which Oracle does not accept as hard partitioning) requires all physical cores in the VMware cluster to be counted, regardless of how many VMs the Oracle instance is actually using.

Your ITAM response to Oracle LMS scripts must include a parallel independent scan using your own tooling, a full mapping of all Oracle product deployments to physical host configurations, documentation of any hard partitioning configurations with evidence that they meet Oracle's Technical Network requirements, and a reconciliation between Oracle's script output and your own measurement. Gaps in this reconciliation, properly documented with explanation, form the basis of your counter to Oracle's initial audit findings.

IBM License Metric Tool (ILMT)

IBM's ILMT is the only Oracle-recognised tool for measuring sub-capacity deployments of IBM software products licensed on a PVU or VPC basis. ILMT tracks the maximum number of virtual processor cores (for VPC-licensed products) or Processor Value Units (for PVU-licensed products) allocated to virtual machines running IBM software, and calculates the licence requirement accordingly.

The PVU-to-VPC transition that IBM executed across its product portfolio over 2020 to 2022 created significant compliance gaps. Products that were licensed on PVU sub-capacity and migrated to VPC in the transition required ILMT reconfiguration to correctly measure VPC rather than PVU metrics. Organisations that did not update their ILMT configuration during the transition may have ILMT data that measures the wrong metric for the audit period, potentially invalidating sub-capacity claims for the years since the metric change.

IBM Cloud Pak deployments add another layer of complexity. Cloud Pak for Data, Cloud Pak for Integration, and other Cloud Pak products bundle OpenShift Container Platform licences within the Cloud Pak entitlement. However, organisations that also purchased standalone Red Hat OpenShift subscriptions before migrating to Cloud Pak may have double-licensed OpenShift — paying separately for OpenShift through Red Hat and receiving it bundled within the Cloud Pak. IBM audits frequently identify this double-licensing scenario and, paradoxically, use it to argue that the organisation's total IBM footprint is larger than the ILMT data suggests, because the standalone OpenShift deployment may not have been correctly captured in ILMT. Ensure your ITAM programme maps every Cloud Pak deployment to its included OpenShift entitlement and removes any redundant standalone OpenShift licensing from the IBM estate baseline.

SAP License Audit Workbench (LAW)

SAP's License Audit Workbench is executed within your SAP environment and produces a report of active named users across all SAP systems, user classifications by licence type, and — in S/4HANA deployments — Digital Access document creation data. The LAW output is the starting point for all SAP compliance reviews, whether conducted proactively by your own team or triggered by an SAP-initiated audit.

The most common SAP audit finding is user classification error: users classified at lower licence tiers (such as Limited Professional User or Employee Self-Service) who are performing system activities that require higher licence types (Professional User or Developer). SAP's licence types are defined by permitted activities, not by roles or system access levels, and the mismatch between your access control configuration and SAP's licence type classification framework is a persistent source of audit exposure.

SAP Digital Access audit findings require a different evidence base: you need to document the specific document types generated by each digital user (third-party system or automated process), map each document type to its applicable pricing model, and confirm that your Digital Access licensing covers the documented interaction volume. If you are in an S/4HANA migration, the Digital Access adoption model introduced during the migration changes your licence obligations compared to the legacy named-user model — and SAP auditors will test whether you have correctly transitioned to the new model.

Microsoft Software Asset Management Tooling

Microsoft's audit engagements are typically conducted through its partner network using Microsoft Assessment and Planning Toolkit (MAP), System Center Configuration Manager (SCCM/MECM) exports, or Microsoft 365 Admin Centre data for SaaS deployments. The data Microsoft seeks covers: Windows Server deployments and their SA/subscription status (for Azure Hybrid Benefit eligibility), SQL Server deployments and their licence type (for determining cloud deployment compliance), Microsoft 365 licence assignments versus active users, and Teams Phone licences relative to configured users.

The Azure Hybrid Benefit (AHB) evidence challenge is particularly complex: AHB allows organisations to use their on-premises Windows Server and SQL Server licences (covered by active Software Assurance) for Azure workloads at a reduced rate. To claim AHB, you must demonstrate that the on-premises SA licences are current, that the licence count applied to Azure workloads does not exceed the on-premises entitlement, and that each licence is not simultaneously used for the on-premises deployment it is meant to cover. This requires precise tracking of SA renewal dates, on-premises deployment counts, and Azure instance configurations across the audit period — data that most ITAM systems capture only partially.

Broadcom / VMware Subscription Compliance Review

Following the January 2024 VMware licensing transition, Broadcom reviews deployments against VCF subscription entitlements rather than perpetual licence counts. The Broadcom compliance review focuses on vSphere host counts, vSAN storage capacity (in TiB), and NSX-T deployment scope, all measured against the VCF subscription purchased. Organisations that deployed VMware under perpetual licensing and have not yet transitioned to VCF subscriptions are the primary target of Broadcom's 2024 and 2025 compliance reviews.

The evidence challenge for VMware/Broadcom audits is generating a current, accurate host and cluster inventory that maps exactly to VCF subscription SKUs. The perpetual licensing model counted vSphere and vSAN separately; the VCF subscription model bundles them, with per-core pricing for compute and per-TiB pricing for storage. An accurate migration from your perpetual inventory to a VCF subscription footprint requires a clean inventory of physical host core counts and deployed vSAN raw capacity — data that many organisations do not have readily available. Given that support cost increases of three to five times typical prior levels are standard under Broadcom's new model, the business case for evaluating Nutanix AOS or Azure VMware Solution as alternatives should be assessed before entering any Broadcom compliance discussion.

Building Your Multi-Vendor Evidence Pack

The evidence pack is the structured set of documents, data exports, and analytical outputs that your organisation presents in response to a software audit. A well-constructed evidence pack does four things: it demonstrates that your internal measurement is accurate and complete, it applies the correct contractual metric to each product deployment, it reduces the vendor's audit claim from gross measurement to true effective licence position, and it presents the resulting compliance status in a format that supports settlement negotiation.

Tier 1: Entitlement Documentation

The foundation of any evidence pack is your licence entitlement record — proof of what you paid for and what you are contractually entitled to deploy. Entitlement documentation should include original purchase orders for all software in scope, software maintenance and support renewal invoices (to confirm SA coverage for Microsoft, subscription currency for Broadcom, and maintenance coverage for Oracle and IBM), any licence transfer agreements, rehosting notifications, or ownership change notifications submitted and confirmed, and contract amendments that modified licence scope, metric, or term.

Entitlement records are often distributed across finance purchase order systems, IT procurement records, vendor portals (Oracle MyOracle Support, IBM Passport Advantage, SAP Support Portal, Microsoft Volume Licensing Service Centre), and paper or email archives. Consolidating them into a single, dated, and sourced entitlement register is the first and most time-consuming step in evidence pack preparation. Do not begin any audit response data collection before this register is complete — without a precise entitlement baseline, you cannot calculate a defensible effective licence position.

Tier 2: Deployment Measurement

Deployment measurement is the technical evidence of what you actually have deployed, expressed in the licence metric units that apply to each product. For IBM middleware, this means ILMT reports covering the entire audit period, with continuous coverage and no measurement gaps. For Oracle database, this means server topology documentation with core counts, VMware cluster membership, and partitioning configuration for every server where Oracle software is detected. For SAP, this means LAW reports and, for S/4HANA, Digital Access document usage reports. For Microsoft, this means SCCM exports, Entra ID reports, and Microsoft 365 Admin Centre data.

The most important principle in deployment measurement preparation is to run your own measurement before the vendor's tool is executed. Your independent measurement, performed before you receive the vendor's scripts or data requests, gives you a baseline that you control. If the vendor's measurement later produces a higher figure, you have the evidence to challenge specific components of the vendor's output. If you run the vendor's tool first without your own baseline, the vendor's output becomes the reference point and you are in the position of disproving it rather than asserting your own positive evidence.

Tier 3: Reconciliation Analysis

The reconciliation analysis is the document that connects your entitlement record to your deployment measurement and calculates your effective licence position. The ELP calculation takes each product, identifies the applicable licence metric, applies the entitlement quantity to the measured deployment quantity, and identifies any shortfall or surplus. For products where the entitlement exceeds the deployment, document the surplus explicitly — it demonstrates compliance and may provide leverage in settlement discussions. For products where the deployment exceeds the entitlement, the shortfall is your exposure and the starting point for settlement negotiation.

Critically, the ELP reconciliation should be prepared by someone with product-specific licence metric knowledge, not by a generalist SAM analyst. IBM sub-capacity calculations require understanding of ILMT scan frequency requirements, VPC counting methodology, and product-specific metric applicability. Oracle ELP calculations require correct application of the Core Factor Table, correct identification of Database Options in use versus licensed, and correct treatment of Test and Development environments if separate licences exist. SAP reconciliation requires correct user classification analysis against the applicable licence type classification framework, not just active user counts. These are technical disciplines that require vendor-specific expertise to perform correctly.

The ITAM Readiness Checklist for Multi-Vendor Audits

Use this checklist to assess your ITAM programme's current readiness for a simultaneous multi-vendor audit across Oracle, IBM, SAP and Microsoft. For each area, assess whether your current capability is absent, partially developed, or fully operational.

Entitlement Management

• Central entitlement register: All licence entitlements for every vendor in scope are recorded in a single authoritative system, updated within 30 days of any purchase, renewal, or contract amendment.
• Vendor portal synchronisation: Oracle MyOracle Support, IBM Passport Advantage, SAP Support Portal, and Microsoft VLSC data is reconciled against your internal entitlement register at least quarterly.
• SA and maintenance coverage tracking: Active Software Assurance, subscription, or maintenance renewal status is tracked per product, per licence, with renewal dates and coverage confirmation held in your entitlement system.
• Historical entitlement archive: All purchase documents, renewal invoices, and licence transfer records are retained for at least seven years and accessible in under 48 hours.

IBM-Specific ITAM Requirements

• ILMT deployment: IBM License Metric Tool is deployed on all servers and virtual environments running IBM software, with continuous scanning without gaps during the audit period.
• ILMT configuration review: ILMT has been configured for VPC metric (not PVU) for all products that migrated from PVU to VPC during the IBM metric transition of 2020 to 2022.
• Cloud Pak / OpenShift mapping: All Cloud Pak deployments are mapped to their included OpenShift entitlements, with standalone Red Hat OpenShift subscriptions reconciled to confirm no double-licensing exposure.
• ILMT data retention: ILMT reports for the full potential audit period (typically three to five years) are retained and accessible.

Oracle-Specific ITAM Requirements

• Hardware topology documentation: Physical server topology, including processor model, core count per processor, and NUMA node configuration, is documented for all servers in scope.
• VMware cluster membership records: vSphere cluster membership for every host running Oracle software is documented, with records of any changes in cluster membership during the audit period.
• Hard partitioning evidence: Where hard partitioning is claimed (Oracle Solaris Zones, IBM LPAR, etc.), the specific configuration and Oracle Technical Network requirements are documented and confirmed.
• Database Options and Management Packs: An authoritative record of Database Options and Management Packs licensed versus those detected in your environment is maintained and reconciled at least annually.

SAP-Specific ITAM Requirements

• Regular LAW execution: SAP License Audit Workbench is run internally at least twice per year, with results analysed for user classification accuracy.
• Digital Access inventory: All third-party systems connecting to SAP (Salesforce, ServiceNow, RPA platforms, custom integrations) are identified and their document interaction volumes are tracked.
• User classification governance: A process exists to review SAP user classifications when roles change, ensuring users are correctly classified to the applicable SAP licence type.

Data Disclosure Controls for Parallel Audit Programmes

When multiple audits are running simultaneously, the data you provide to each vendor must be carefully controlled to prevent cross-vendor information leakage that expands your exposure beyond the contractually authorised scope of each audit. This is not about withholding legitimate data — it is about ensuring that each vendor receives only the data they are entitled to, nothing more.

Scoping Data Extraction by Product and System

Audit data should be extracted at the product and system level, not at the estate level. When Oracle requests a server inventory, the data extracted should cover only the servers where Oracle software is deployed, not your entire infrastructure inventory. When IBM requests ILMT data, the export should cover only IBM-licensed products, not the full ILMT discovery output that may include non-IBM software installations from other vendors.

Most ITAM and SAM tools generate exports that cover more than the contractually required scope by default. Before every data extraction for audit purposes, define the exact scope parameters in your ITAM tool and confirm that the output covers only the applicable systems, products, and time periods. Document the scope parameters used for each extraction and retain that documentation alongside the extraction output.

Metadata Scrubbing

ITAM tool exports and server inventory reports frequently contain metadata beyond the specific fields requested by the auditor: system comments, configuration notes, planned migration annotations, licensing status notes from other vendor programmes, and similar supplementary information that may reference compliance gaps in products outside the current audit scope. Before submitting any data file to an auditor, review the file for metadata that exceeds the contractual scope and remove or redact it with a clear notation in your cover letter explaining that the redactions relate to data outside the scope of the current audit.

Audit Data Log and Chain of Custody

Maintain a precise log of every data file submitted to every auditor, including the submission date, the data scope, the format, and the specific data fields included. This chain of custody documentation protects you if a vendor later claims that you disclosed information beyond the current audit scope, or claims that you failed to disclose information that you actually did provide. In multi-vendor audit environments, vendor audit teams have been known to compare notes on large accounts, and your data log is the authoritative record of what you provided to whom and when.

Resolving Evidence Conflicts Between Vendor Measurements

In complex IT environments, it is common for different vendors' audit tools to produce conflicting data about the same systems. Oracle's LMS scripts may count processor cores differently from your SCCM discovery data. IBM's ILMT may report a different virtual processor core count for a shared host than your VMware vCenter shows. These conflicts are not necessarily the result of error — they may reflect different methodologies for measuring the same physical reality.

When evidence conflicts arise, the correct approach is to produce a technical reconciliation document that explains the source of the discrepancy, identifies which measurement methodology is contractually required, and demonstrates that your ITAM data, correctly interpreted against the contractual metric, produces a more accurate result than the vendor's tool output. This reconciliation requires both technical depth (understanding why the two measurement methods produce different outputs) and contractual expertise (knowing which measurement methodology the licence agreement actually requires).

In virtually every case we have handled, when a technical reconciliation is presented professionally with supporting evidence, the auditor's team acknowledges the discrepancy and adjusts their findings accordingly. Vendor audit teams are commercial teams, not technical forensic investigators. A well-evidenced technical challenge to their measurement will almost always be accepted if it is presented clearly and supported with documented evidence.

Building Long-Term Multi-Vendor Audit Readiness

Reactive audit response is expensive, stressful, and commercially unfavourable. The organisations that consistently achieve the best audit outcomes — minimal shortfall claims, rapid resolution, and favourable settlement terms — are those that invest in proactive multi-vendor audit readiness as a continuous capability, not a crisis response.

The return on investment from proactive ITAM maturity is substantial and measurable. Organisations with mature SAM programmes reduce their average audit settlement cost by 40 to 60 percent compared to organisations responding reactively. They reduce the internal resource cost of audit response by 70 to 80 percent, because the evidence that would take weeks to reconstruct under an audit deadline is already current and accessible. They reduce the business disruption of audit programmes from months to weeks, because their data is ready to deliver at the first request and their commercial position is established before the vendor's measurement tool runs.

The specific investment priorities for multi-vendor ITAM readiness are: deploying ILMT correctly for IBM (this is the single highest-return ITAM investment for any enterprise with significant IBM middleware), maintaining Oracle hardware topology data with VMware cluster membership records, running SAP LAW internally on a semi-annual basis, and synchronising Microsoft VLSC and M365 Admin Centre data with your internal ITAM system quarterly. These four vendor-specific data streams, maintained continuously, cover the vast majority of enterprise software audit exposure from the four largest audit programmes in the market.

At Redress Compliance, our ITAM advisory practice helps enterprises build and validate the specific vendor data streams required for multi-vendor audit readiness. We work exclusively on the buyer side, and our ITAM maturity assessments focus on the evidence gaps that matter most commercially — not generic SAM best practices that do not translate into audit defence capability.