€7.7 Million Saved
on Oracle Database Audit

Background — A Financial Services Organisation Under Oracle Scrutiny

Financial services organisations are among Oracle's most valuable audit targets. Their IT estates are typically large, complex, and long-lived — meaning Oracle Database deployments that were configured years ago under different licensing rules may now represent significant compliance exposure under Oracle's current interpretation of its policies. Banks, insurers, and asset managers also have strong incentives to settle quickly and quietly to avoid regulatory scrutiny of any compliance gap acknowledgement.

This southern European bank had been running Oracle Database Enterprise Edition across multiple data centres for over a decade, supporting core banking applications, risk systems, and reporting infrastructure. The estate included both physical and virtualised deployments across VMware clusters, with Oracle Database options including Oracle Partitioning and Oracle Advanced Compression enabled across various instances.

Oracle's GLAS (Global Licensing and Advisory Services — the rebranded successor to LMS) team initiated the audit under the standard contractual audit right provision. The bank's initial response was to handle the audit internally, engaging their Oracle account team and working through Oracle's data collection process without independent advisory support. This approach — well-intentioned but commercially costly — shaped the audit outcome from the outset.

The Audit Report — Oracle's €8 Million Claim

Eight weeks after the data collection was completed, Oracle delivered its audit report. The total compliance claim was €8 million, comprising two primary components: a significant Oracle Database Enterprise Edition Processor licence shortfall attributable to virtualisation over-counting across VMware clusters, and alleged unlicensed use of Oracle Database options — specifically Oracle Partitioning and Oracle Advanced Compression on instances that Oracle's analysts argued were not covered by the bank's existing licence entitlements.

The bank's internal legal and procurement teams reviewed Oracle's report and concluded that the technical findings appeared sound — the descriptions of virtualisation configurations and database options usage matched their own understanding of the environment. At this point, the bank was contemplating a negotiated settlement in the range of €5–6 million, accepting Oracle's technical position and seeking only a commercial discount.

Redress Compliance was engaged before any formal response was provided to Oracle. This timing was critical — once an organisation acknowledges the technical validity of an Oracle audit finding in writing, negotiating that position down becomes substantially harder. Redress advised the bank to request a technical review extension from Oracle (standard practice, and generally granted) and conducted an independent analysis of Oracle's findings before any substantive response was issued.

The Technical Review — Where Oracle Was Wrong

Redress Compliance's technical review of Oracle's €8 million claim identified errors in both major components of the audit findings. The scale of the errors — and the fact that Oracle's report appeared internally consistent and technically plausible to non-specialists — underscores why independent expert review is essential in any significant Oracle audit.

Virtualisation Counting Errors

Oracle's claim on Processor licence shortfalls was based on the assertion that the bank's VMware clusters required full-cluster licensing. This is Oracle's standard position for VMware deployments — Oracle does not recognise VMware as hard partitioning, and requires that all physical hosts capable of running Oracle workloads be licensed.

However, Oracle's analysis had applied this principle incorrectly to several environments. First, two VMware clusters had been specifically configured with host affinity rules in vSphere that bound Oracle VMs to designated hosts within the cluster — a configuration that, while not qualifying as Oracle-recognised hard partitioning, represented a documented and auditable control limiting Oracle workload mobility. When Redress presented the vCenter configuration documentation and change management records showing these affinity rules had been in place continuously throughout the audit period, Oracle's basis for full-cluster licensing of those environments was substantially weakened.

Second, a cluster that Oracle had included in the Processor count had been decommissioned and replaced twelve months prior to the audit. Oracle's data collection had captured installation records from the decommissioned environment (standard Oracle LMS collection pulls historical data), but the physical servers had been removed from service. Oracle had counted these decommissioned servers as active Processor requirements. Hardware decommission documentation, asset disposal records, and support team change management tickets all confirmed the environment was no longer in use during the claimed non-compliance period.

Database Options Licensing

Oracle's claim that Oracle Partitioning and Oracle Advanced Compression were being used without licence was technically accurate for a subset of instances — but Oracle had significantly over-counted the scope of unlicensed usage. Oracle's collection script identifies feature usage through Oracle's feature usage tracking views (V$OPTION, DBA_FEATURE_USAGE_STATISTICS), which record whether a feature has ever been used, not whether it is currently in active use or whether it was used after the licence restriction applied.

Redress worked with the bank's DBA team to produce query-level evidence demonstrating that several instances flagged by Oracle had recorded Partitioning usage from pre-migration periods — the data in Oracle's feature usage views reflected historical activity from a prior architecture before certain databases were migrated to instances the bank did not hold options licences for. The usage timestamps in Oracle's own data contradicted Oracle's representation of ongoing unlicensed use.

Negotiation — From €620K to €300K Settlement

Redress presented the counter-analysis to Oracle's GLAS team in a structured written response, supported by technical appendices covering each challenged finding. Oracle's initial counter-response accepted the decommissioning argument (reducing their claim materially) but maintained its position on the virtualisation affinity rule analysis and the database options scope.

The subsequent negotiation involved two additional rounds of written exchange, during which Redress provided increasingly specific technical evidence on each contested point. By the third round, Oracle's analysts had substantially accepted the vCenter affinity configuration evidence, and the remaining disputed items were commercially manageable.

The bank's position in the negotiation was strengthened by two factors beyond the technical analysis: the bank had a significant Oracle renewal coming up within eighteen months, and it was genuinely evaluating alternatives for a subset of its Oracle Database workload as part of a broader IT cost reduction programme. Oracle's account team was aware that the audit outcome would significantly influence the renewal relationship, and Oracle's commercial interest in maintaining a positive account relationship — and retaining the upcoming renewal — provided additional leverage that Redress explicitly incorporated into the negotiation strategy.

The settlement of €300,000 — a 96% reduction from Oracle's initial €8 million claim — included a clean compliance letter, a forward-looking licence position confirmation, and a negotiated support discount on the bank's upcoming Oracle renewal. The bank's total cost of the Redress Compliance engagement, including both the technical review and the negotiation, was recovered approximately fifteen times over in the settlement reduction alone. For more Oracle audit case studies, see Redress Compliance's full library.

Key Lessons — What This Case Teaches Every Oracle Customer

Three observations from this case are applicable to any organisation navigating an Oracle audit. First, the timing of independent engagement matters enormously. The bank's initial instinct to handle the audit internally — before engaging expert support — limited but did not eliminate Redress's ability to challenge Oracle's findings. Had independent advisors been engaged before the data collection was submitted, there would have been opportunity to shape the collection outputs and reduce the evidential basis for some of Oracle's claims. Engaging at the audit report stage is far better than not engaging at all; engaging at the notification stage is better still.

Second, Oracle's audit reports routinely contain technical errors that are invisible to non-specialists. The bank's internal team reviewed Oracle's report and found it credible — because the findings described real environments and real feature usage. Only an advisor with deep knowledge of Oracle's methodology, common error patterns, and the specific rules for virtualisation and options counting was able to identify where Oracle's analysis had misapplied the evidence. The lesson is not that the bank's internal team was incompetent — it is that Oracle audit analysis requires specialised expertise that most organisations do not maintain internally.

Third, the audit and the commercial relationship are inseparable. Oracle's account team and its GLAS audit team operate with different objectives, but they sit within the same organisation. The upcoming renewal created genuine commercial incentive for Oracle to resolve the audit at a number that preserved the relationship. Understanding this dynamic — and using it strategically — is part of what experienced Oracle advisors do. Contact Redress Compliance to discuss how we approach Oracle audit engagements and what outcomes are achievable in your specific situation.