IBM Audit Defense for a Swiss Financial Services Firm

Client Profile

The client is a Swiss private bank headquartered in Zurich, managing approximately CHF 52 billion in assets under management. With around 1,800 employees across offices in Geneva, Lugano, and Singapore, the organisation provides wealth management, investment advisory, and fiduciary services to institutional and high-net-worth clients. Its IBM estate spans WebSphere Application Server, IBM MQ, IBM DB2, IBM DataPower Gateway appliances, and a more recent IBM Cloud Pak for Integration deployment on Red Hat OpenShift. The IBM Software License Review notice arrived in Q4 2025, shortly after the bank's five-year ELA had expired without renewal — a well-documented trigger for IBM audit activity.

The Challenge

IBM's opening claim of CHF 3.2M rested on three separate compliance arguments. Each contained a material error. Together they produced a claim that substantially overstated the bank's genuine licence exposure.

ILMT Sub-Capacity Gaps on VMware Infrastructure

During an infrastructure refresh programme completed 18 months before the audit notification, nine new ESXi hosts had been provisioned and brought into production without ILMT agents installed within IBM's mandatory 90-day deployment window. IBM's auditors applied full-capacity pricing across all IBM software on VMs hosted on those nine servers for the full 19-month gap period, covering WebSphere Application Server and DB2 workloads. IBM's calculation treated each host as if all physical cores were continuously dedicated to IBM software. In this environment, VMware DRS and CPU resource pool limits were active across all clusters — constraining IBM software VMs to a defined share of physical core capacity throughout the gap period. IBM's inflated ILMT claim totalled CHF 1.8M.

Cloud Pak VPC Licensing Miscalculation

IBM Cloud Pak for Integration is licensed on a Virtual Processor Core (VPC) metric — the vCPUs assigned to IBM Cloud Pak pods at peak consumption within the OpenShift cluster. IBM's auditors had instead calculated the VPC requirement based on the total vCPU capacity of every worker node, treating the entire cluster as licensed capacity regardless of workload mix. The bank ran a mixed OpenShift environment with IBM Cloud Pak components occupying approximately 35% of cluster capacity at peak, overstating the VPC requirement by a factor of 2.8. IBM's inflated Cloud Pak claim totalled CHF 0.9M.

DataPower Appliance Double-Count

IBM's claim included CHF 0.5M relating to two IBM DataPower Gateway appliances that IBM asserted were unlicensed. IBM's audit inventory had listed four DataPower appliances at the bank's Zurich datacentre. The bank operated only two. Two appliances that had been decommissioned and physically removed from service 26 months prior to the audit had remained in IBM's internal asset registry — a legacy of an incomplete decommission notification submitted to IBM at the time of removal. IBM had not updated its records, and its audit team had built its claim on the outdated inventory.

The Approach

Redress Compliance was engaged seven days after the bank received IBM's formal audit findings report. The engagement was structured across three concurrent workstreams: technical remediation of the ILMT deployment gap, methodology challenge on the Cloud Pak VPC calculation, and inventory correction for the DataPower double-count.

ILMT Remediation and PVU Methodology Challenge

ILMT agents were deployed across all nine previously unmonitored ESXi hosts within four days of engagement, establishing a compliant forward-looking position. The methodology challenge focused on IBM's full-capacity PVU baseline for the gap period. Analysis of VMware vCenter configuration history confirmed that CPU resource pools with hard limits had been active across all four clusters throughout the 19-month gap. Per-VM CPU limits for IBM software workloads on the affected hosts — extracted from vCenter archives — demonstrated that IBM software had access to an average of 41% of each host's maximum physical core count. This reduced the defensible full-capacity PVU baseline by 59%, cutting the ILMT-related claim from CHF 1.8M to approximately CHF 735K before commercial negotiation.

Cloud Pak VPC Recalculation

Pod-level resource allocation data extracted from the bank's Prometheus monitoring stack — covering the 24 months preceding the audit — confirmed that IBM Cloud Pak components had never exceeded 38% of cluster vCPU capacity at peak. A corrected VPC calculation from this data reduced IBM's Cloud Pak claim from CHF 0.9M to CHF 185K, a CHF 715K reduction achieved through accurate application of IBM's own metric. IBM accepted the Prometheus-based calculation without challenge.

DataPower Inventory Correction

Decommission documentation for the two removed DataPower appliances — including physical deinstallation records, datacentre cage access logs, and the original incomplete decommission notification submitted to IBM — was compiled and submitted to IBM's audit team. IBM accepted the corrected two-appliance inventory and withdrew the CHF 0.5M DataPower claim in its entirety.

Commercial Settlement

With the Cloud Pak and DataPower components resolved and the ILMT claim reduced to CHF 735K on technical grounds, Redress Compliance entered structured commercial settlement negotiations on the residual ILMT shortfall. The negotiation focused on IBM's back-maintenance calculation and the appropriate forward-looking compliance commitment. A final settlement of CHF 485K was agreed over six weeks, incorporating a reduced back-maintenance rate for the corrected shortfall period and a two-year licence position review commitment in lieu of further audit activity.

The Outcome

The final settlement of CHF 485K represented an 85% reduction from IBM's opening claim of CHF 3.2M — a saving of CHF 2.715M. The Cloud Pak VPC recalculation alone eliminated CHF 715K through technical methodology correction. The DataPower inventory correction eliminated CHF 500K without any commercial negotiation. The ILMT methodology challenge reduced the residual claim by CHF 1.065M, with commercial negotiation delivering a further CHF 250K reduction on the corrected shortfall. The full engagement ran 14 weeks from initial instruction to IBM's formal closure of the Software License Review.

The bank exited the engagement in a fully defensible IBM licence position. ILMT was deployed and correctly configured across all 32 ESXi hosts, with automated quarterly snapshot generation in place. A Cloud Pak VPC monitoring dashboard was established using the bank's existing Prometheus infrastructure, providing ongoing visibility of IBM pod-level consumption. IBM's asset registry was corrected and the bank implemented a formal IBM asset notification procedure to ensure decommission events are reflected in IBM's records at the point of physical removal.

Key Takeaways

Three patterns from this engagement apply broadly across IBM financial services audits. First, IBM's full-capacity PVU calculations for ILMT gap periods routinely ignore VMware CPU resource pool limits that are standard practice in enterprise virtualisation. vCenter configuration archives documenting those limits are available in most environments and can substantially reduce IBM's gap-period methodology before any commercial negotiation begins.

Second, IBM Cloud Pak VPC claims built on cluster-level capacity overstate licence requirements for any organisation running mixed OpenShift workloads. Prometheus monitoring data is a directly auditable and IBM-accepted basis for correcting those calculations — and in this case eliminated CHF 715K without any commercial negotiation whatsoever.

Third, IBM's asset registry is not self-correcting. Hardware decommissioned without a confirmed IBM asset update remains in IBM's records and can generate audit claims years later. Verifying that IBM's inventory reflects current infrastructure — not historical snapshots — before responding to any information request is a structural requirement of defensible IBM audit management.