Virtualisation & Cloud: The New Software Audit Battleground

Why Cloud Creates Audit Exposure

Software licensing models were designed for physical, static infrastructure. When a server had a defined processor count and software ran on that server, licence calculations were relatively straightforward. Virtualisation and cloud computing have fundamentally changed this — workloads can move between hosts, processing capacity can scale dynamically, and the boundary between "running" and "available to run" has become blurred in ways that vendors have exploited to create expanded licence obligations.

The core problem is that enterprise software vendors — particularly Oracle, IBM, and SAP — have applied licence metric interpretations to virtualised and cloud environments that dramatically expand the licence obligation beyond what most customers understand when they purchase on-premise licences. The same licence that covered a workload on a physical server may require significantly more licence units when that workload is migrated to a virtual machine or cloud instance, even if the actual computational workload has not changed.

Understanding these positions is essential to managing both compliance and audit risk. The complete audit defense framework is covered in the Software Audit Defense Playbook. This article focuses on the virtualisation and cloud compliance issues specifically.

Oracle's Virtualisation Licensing Position

Oracle's virtualisation licensing policy is arguably the most aggressive and most contentious in the enterprise software market. Oracle's position is that database and middleware licences must be calculated based on all physical processor cores in any host where Oracle software could theoretically run — not just the virtual cores allocated to the specific virtual machines running Oracle software.

Oracle recognises only "hard partitioning" technologies as eligible for sub-capacity licensing — meaning the virtual machine has been given an exclusive, guaranteed allocation of processing resources that cannot be exceeded or shared. Oracle's own virtualisation technology (Oracle VM Server for x86) qualifies, as does Oracle Solaris Zones with specific configuration, IBM LPAR (with some restrictions), and a small number of others. VMware vSphere — the most widely deployed virtualisation platform in the enterprise market — does not qualify for hard partitioning treatment.

The practical consequence is severe: an organisation running Oracle Database on a VMware cluster with 40 physical processor cores must licence all 40 cores, regardless of whether only a small subset of those cores ever hosts Oracle workloads. A VMware cluster that costs $500,000 in virtual infrastructure may require $4 million or more in Oracle processor licences if the full-capacity obligation is applied. This is the most common finding in Oracle audits of virtualised environments.

Oracle on Public Cloud

Oracle's position on public cloud deployments is covered by a separate policy document (the "Licensing Oracle Software in the Cloud Computing Environment" policy) that has been updated multiple times and is deliberately complex. The current position allows sub-capacity licensing on AWS, Azure, and GCP under specific conditions — but only for instances designated as "Authorised Cloud Environments" and only using approved instance types. Running Oracle on an instance type that is not on Oracle's authorised list can trigger full-capacity obligations across the entire cloud account.

IBM's Cloud and Virtualisation Licensing

IBM's sub-capacity licensing programme offers a more workable path to cloud compliance than Oracle's policy, but it comes with its own significant compliance requirements — primarily the mandatory deployment of ILMT (IBM License Metric Tool) to every endpoint running eligible IBM software. The ILMT compliance guide covers the specific requirements in detail.

For cloud deployments, IBM has a specific Cloud Programme that allows sub-capacity licensing on authorised cloud providers, but the programme requires annual registration and has specific terms that differ from on-premise sub-capacity rules. IBM software running on cloud infrastructure without proper programme enrolment may be subject to full-capacity pricing, a position IBM has enforced in audit settlements.

Container and Kubernetes environments present particular challenges for IBM licensing. The rapid creation and destruction of containers, combined with the difficulty of applying traditional licence metric calculations to ephemeral workloads, creates compliance ambiguity that IBM's audit team tends to resolve in the direction of maximum licence obligation. Organisations running IBM software in containerised environments should obtain written guidance from IBM on the applicable licence metric calculation before deployment, not after.

SAP in Cloud and Hybrid Environments

SAP's primary cloud compliance challenge is not infrastructure-based but integration-based. SAP's indirect access policy — the requirement to licence external users who access SAP data through third-party systems — applies regardless of whether SAP is deployed on-premise or in the cloud. A cloud-native application that reads SAP data through an API, a robotic process automation tool that writes to SAP tables, or an e-commerce platform that creates SAP sales orders all potentially create indirect access licence obligations.

Cloud migrations that introduce new integration patterns between SAP and cloud-native applications are therefore a significant audit trigger. SAP account teams monitor implementation partner activity and customer success contacts for evidence of new integration projects, and this information can be used to initiate an indirect access audit. The SAP indirect access defense guide covers the specific compliance and negotiation positions available.

Managing Virtualisation and Cloud Compliance

The starting point is a cloud and virtualisation licensing assessment — a structured analysis of every cloud and virtualised environment where enterprise software is deployed, mapping each deployment against the applicable licence policy for that vendor and environment type. This assessment identifies the current compliance position and prioritises remediation where gaps exist.

For Oracle environments, the practical options are: migrating to Oracle VM Server or another hard partitioning technology (expensive and disruptive), purchasing sufficient Oracle licences to cover the full physical processor count (often prohibitively expensive), migrating the Oracle workload to Oracle Cloud Infrastructure (where Oracle offers more favourable licensing terms), or negotiating a ULA or similar instrument that provides unlimited deployment rights for a fixed fee. Each option requires careful analysis — IT Negotiations' Oracle advisory practice supports all four approaches.

For IBM environments, the remediation path is almost always ILMT remediation — deploying ILMT to all endpoints, restoring continuous reporting, and building the ongoing programme management to prevent future gaps. For SAP environments, indirect access remediation requires either licensing the indirect access appropriately, restructuring integrations to reduce the access footprint, or negotiating a digital access or RISE commercial structure that provides comprehensive coverage.