Why Multi-Vendor Audit Readiness Is Different from Single-Vendor Preparation
Most software audit defence frameworks are built around individual vendor programmes — Oracle's LMS engagement process, SAP's Digital Access audit methodology, IBM's ILMT compliance requirements, and Microsoft's True-Up process. Each vendor has distinct licensing rules, audit triggers, and compliance evidence requirements. Preparing for each independently is necessary but insufficient.
Multi-vendor audit readiness requires an additional layer of coordination: ensuring that the evidence, data collection, and response communications for each vendor are managed independently without cross-contaminating each case. Organisations that allow Oracle's audit team to observe their SAP compliance status — or that produce deployment data for IBM that inadvertently illuminates Microsoft compliance gaps — create compounded exposure that exceeds the sum of individual vendor risks.
The checklist below is structured in two parts: the universal preparation elements that apply across all vendors, followed by the vendor-specific items that each of the four major audit sources requires.
Universal Readiness Checklist: Cross-Vendor Foundations
These preparation steps apply regardless of which vendor is conducting the audit. They form the foundational readiness posture that reduces exposure and response time for any vendor demand.
Foundation: Licence Entitlement Repository
Maintain a centralised licence entitlement registry covering all active contracts, order forms, and purchase records for each vendor, updated at each renewal and procurement event.
Map each contract to specific entitlements — product names, metric definitions, version rights, deployment scope, and affiliate usage authorisations — not just total licence counts.
Retain all historical purchase documentation including original licence agreements, addenda, order forms, and amendment letters for the full audit look-back period (typically 7 years for most vendors).
Document all licence transfers, migrations, and downgrades between product versions, deployment models, and metric types — each transition creates a compliance evidence requirement.
Foundation: Deployment Inventory
Maintain a current software deployment inventory covering all production, non-production, development, test, and disaster recovery environments — auditors assess all environments unless explicitly excluded by contract.
Run internal deployment scans at least quarterly using SAM tools (Flexera, Snow, ServiceNow) to identify software installations that may not be reflected in formal procurement records.
Document all cloud and virtualised deployments separately — cloud deployments often carry different licensing rules than on-premises installations, and virtualisation technology (VMware, Hyper-V, cloud VMs) affects licence metric calculations for IBM, Oracle, and Microsoft differently.
Received an audit letter from Oracle, SAP, IBM, or Microsoft?
Redress Compliance provides immediate audit defence advisory — call us before you respond to the vendor or provide any data.
Get Immediate Help →
Oracle Audit Readiness Checklist
Oracle conducts audits through its Licence Management Services (LMS) team. Oracle audits are triggered by cloud migration activities, hardware upgrades, mergers and acquisitions, and periods of no procurement activity. Oracle's audit scope is broad and its methodology — particularly around virtualisation and processor metric calculations — creates significant exposure for organisations without precise deployment documentation.
Oracle-Specific Preparation
Virtualisation documentation is the highest Oracle audit risk. Every Oracle deployment on VMware, Hyper-V, or public cloud must be documented against Oracle's hard partitioning rules. Soft partitioning does not limit Oracle's licence count — all physical cores on hosts that have ever run Oracle workloads may be countable.
Maintain Oracle-specific processor counts including the processor factor applicable to each chip architecture (Oracle's Processor Core Factor Table applies different multipliers by chip type).
Document all Oracle products across all environments — Oracle's audit scope includes database, middleware, and applications even if only one product category was purchased. Database options and management packs auto-activate if installed.
Never respond to Oracle LMS data requests without independent legal and advisory review. The data Oracle requests is specifically designed to maximise its compliance claim — independent review consistently identifies material scope differences between what Oracle requests and what is contractually required.
SAP Audit Readiness Checklist
SAP's audit methodology shifted significantly with the introduction of Digital Access licensing in 2018. Organisations running legacy indirect access structures are at highest risk, as SAP's Digital Access model monetises third-party system connections that previously fell outside licence scope.
SAP-Specific Preparation
Map all system integrations that touch SAP — every external system, middleware layer, and API that creates, reads, or updates SAP documents may represent Digital Access exposure under SAP's current audit methodology.
Audit named user classifications annually — SAP named user types carry significantly different licence costs (Professional vs Limited Professional vs Employee), and reclassification is a primary SAP audit finding.
Document all non-SAP RPA and automation tools that interact with SAP — robotic process automation creates indirect access document counts that SAP's audit team will assess against Digital Access licence entitlements.
If you have a pre-2018 indirect access agreement, obtain written confirmation from SAP of how that agreement applies to your current integration architecture — do not assume historical terms cover current integration patterns.
IBM Audit Readiness Checklist
IBM's licensing complexity is among the highest of any enterprise software vendor. ILMT (IBM License Metric Tool) is the cornerstone of IBM sub-capacity compliance — organisations that do not have ILMT correctly configured are exposed to full-capacity PVU billing regardless of actual deployment footprint. The PVU-to-VPC metric transition that IBM began in recent years created compliance gaps for organisations that did not update their ILMT configuration and reporting structure when their products transitioned between metrics.
IBM-Specific Preparation
ILMT must be correctly configured and actively reporting for all IBM software entitled to sub-capacity licensing. Sub-capacity licensing — which can reduce licence costs by 40 to 70 percent versus full capacity — is only valid when ILMT is properly deployed, configured, and its reports are retained for audit purposes.
Confirm which IBM products have transitioned from PVU to VPC metrics. The PVU-to-VPC transition created compliance gaps for organisations that did not update their licence position calculations when products changed metrics — verify each product's current metric against your contract.
Audit all IBM Cloud Pak deployments for OpenShift entitlement. IBM Cloud Pak bundles include Red Hat OpenShift, and organisations that deployed OpenShift separately before or alongside Cloud Pak are at risk of double-licensing — paying for OpenShift both within the Cloud Pak bundle and as a standalone entitlement.
Retain ILMT peak usage reports for the full IBM audit look-back period and ensure ILMT is updated to reflect current product versions — outdated ILMT versions may not correctly report against current metric definitions.
"The organisations that come out of software audits with the lowest cost settlements are consistently those that started their preparation before the audit letter arrived — not after."
Microsoft Audit Readiness Checklist
Microsoft conducts licence compliance reviews (LCRs) through its SAM engagement process. Microsoft audits are less adversarial in tone than Oracle or IBM audits but can produce significant financial exposure, particularly for organisations that have undergone cloud migration without aligning on-premises licence reductions with actual deployment changes.
Microsoft-Specific Preparation
Align True-Up positions accurately at each EA anniversary. Under-reporting at True-Up creates retrospective liability; over-reporting at True-Up creates unnecessary cost. Accurate annual True-Up management requires a current deployment inventory against contracted entitlements, not estimates.
Document all Windows Server and SQL Server deployments in cloud environments. BYOL (Bring Your Own Licence) rights apply differently across AWS, Azure, and GCP, and the Azure Hybrid Benefit rules for SQL Server and Windows Server have specific eligibility requirements that are frequently misapplied.
Confirm all Microsoft 365 user assignments are current. Microsoft's SAM reviews focus heavily on user-based metrics — unassigned licences and former employee accounts that retain active assignments are common findings that inflate True-Up costs.
Assess Visual Studio and developer licence assignments annually — these are frequently over-assigned and represent a significant audit finding category in organisations with large development teams.
Managing Simultaneous Multi-Vendor Audits
When two or more major vendors initiate audits simultaneously — a scenario that is increasingly common following M&A activity, cloud migration programmes, or procurement freezes — coordination becomes critical. Several principles apply.
Appoint a single audit coordinator: Multi-vendor audits require a single internal owner who manages the response process for all vendors, ensures that data shared with one vendor does not inadvertently assist another, and coordinates with external advisors across all active cases. Without a single owner, different teams responding to different vendors can produce inconsistent positions that auditors exploit.
Engage legal counsel before any data is provided: The first communication from any vendor audit team should trigger immediate engagement of legal counsel experienced in software licensing. This is non-negotiable. Audit teams are structured to obtain the maximum possible compliance data with the minimum possible adversarial friction. Legal counsel ensures that any data request is reviewed against contractual audit rights before compliance.
Sequence your responses strategically: If multiple audits are running simultaneously, the order in which you resolve each case matters. Settling with IBM before completing Oracle's audit may provide Oracle's team with useful information about your deployment practices. Where possible, manage the audit resolution sequence so that each settlement is completed before the next begins — or at minimum ensure that settlement communications are confidential and explicitly excluded from sharing with other vendors.
Preparing proactively for vendor audits or currently under investigation?
Redress Compliance provides audit defence support across Oracle, SAP, IBM, and Microsoft — simultaneously or independently.
Contact Our Audit Team →