Oracle Audit Remediation: Fix the Right Gaps

What the Settlement Actually Resolves — and What It Does Not

Oracle audit settlements resolve the historical compliance claim for the period covered by the audit. They do not automatically resolve current or future compliance obligations, and they rarely include provisions that protect you from a follow-on audit. The typical Oracle LMS settlement covers a defined back-licence period — often three to five years — and results in either additional licence purchases or a restructured commercial arrangement. Once signed, the audit is closed. But the deployment environment that created the compliance gap still exists, and Oracle can re-audit it at any point.

The settlement document itself is important. Review the settlement language carefully for any provisions that Oracle uses as baseline measurements for future licences. Settlements that include language such as "Customer acknowledges current deployment of X processor licences" effectively reset your licence baseline to Oracle's audit count — which, as discussed throughout our audit guide, is almost always higher than the legitimate count. Accepting Oracle's baseline in a settlement creates a higher starting point for future licence obligations.

Equally important: settlements sometimes include prospective licence commitments or cloud transition provisions that Oracle has structured to benefit Oracle rather than the customer. The combination of a compliance settlement and a new cloud commitment — which Oracle's GLAS team has made standard practice in settlement negotiations — should be evaluated independently by your contract negotiation advisor before signing.

Post-Audit Gap Analysis: Understanding What You Actually Have

Before beginning remediation, you need a clear, independent picture of your current Oracle compliance position. This is different from Oracle's audit findings. Oracle's audit was designed to identify your maximum exposure; a post-audit gap analysis is designed to identify your actual position — what you genuinely owe, what you genuinely over-licence, and where the structural risks are.

A proper post-audit gap analysis covers four dimensions. First, the software inventory: every Oracle product installed in your environment, the version, the deployment platform, and the licence metric that applies. This includes products you may not have knowingly licenced — Oracle software that arrived with application server bundles, database options enabled by default, or Java SE installations on application servers. The compliance review service produces this inventory as the first deliverable.

Second, the entitlement review: every Oracle licence you hold, the precise product, metric, and quantity on each Order Form, and the contract terms that govern each deployment. Many enterprises discover during this review that they hold licences they are not using — legacy entitlements from acquisitions, products replaced by newer versions, or over-licenced metrics from previous commercial negotiations. These over-licences can offset genuine gaps in the optimisation phase.

Third, the gap calculation: the difference between what Oracle's LMS methodology would count in your current environment and what your current entitlements cover. This is the number that Oracle will use as a starting point in the next audit — and it is the number your remediation programme needs to close. The audit defence team calculates this independently using the same methodology Oracle applies, so there are no surprises when Oracle next engages.

Fourth, the risk prioritisation: not all compliance gaps carry equal audit risk. A gap in Oracle Database Enterprise Edition processor licences — Oracle's primary audit target — is higher priority than a gap in a middleware product that Oracle rarely audits. Prioritisation ensures that remediation resources address the exposure that actually affects your risk profile.

Phase 1: Immediate Technical Remediation

Technical remediation addresses the actual deployments that created the compliance gap. This phase begins immediately after the post-audit gap analysis and focuses on actions that reduce your ongoing compliance exposure without requiring licence purchases. The goal is to get your deployment aligned with what you actually have licenced — removing or restricting Oracle software that is deployed beyond your entitlements.

Phase 2: Licence Right-Sizing and Commercial Optimisation

After technical remediation reduces your deployment footprint, Phase 2 addresses the commercial side: restructuring your Oracle licence estate to match your actual requirements at the most efficient cost. This phase is where independent advisory expertise has the highest financial impact. Oracle's natural incentive is to maintain or expand your licence spend; your incentive is to right-size it to what you genuinely need.

Identify and Eliminate Over-Licencing

Most Oracle customers who have been through an LMS audit are over-licenced in some areas and under-licenced in others. The audit process focuses exclusively on under-licencing — the gaps where Oracle can make claims. It deliberately ignores over-licencing because returning surplus licences would reduce Oracle's revenue. An independent gap analysis identifies both, and a proper optimisation programme captures the surplus — either through licence returns in the next EA renewal, metric conversions, or deliberate changes to how Oracle software is deployed. The licence optimisation service structures this process across your entire Oracle estate.

Restructure Metric Alignments

Oracle's audit claim is stated in Oracle's preferred metric — usually Processor licences at maximum scope. The post-audit commercial negotiation is an opportunity to restructure the metric more intelligently. In some environments, Named User Plus (NUP) licences — priced per defined user rather than per processor core — are significantly cheaper for the same deployment, depending on user counts and Core Factor multipliers. The break-even analysis between Processor and NUP metrics is a standard component of the NUP vs Processor metric analysis.

Java SE deployments are particularly important to address in Phase 2. If the audit identified Java SE Employee Metric exposure, a post-audit remediation programme for Java includes migrating to OpenJDK where technically feasible, implementing a Java deployment policy that controls which JRE distributions are used across the enterprise, and right-sizing Oracle Java SE subscription scope to the minimum defensible employee population. The Java licensing advisory service specialises in this analysis.

Evaluate Third-Party Support

If the audit revealed significant Oracle support spend on databases or applications that have been heavily customised or are not receiving meaningful Oracle development investment, the post-audit period is the optimal time to evaluate third-party support alternatives. Third-party support for Oracle Database and Oracle applications (EBS, PeopleSoft, JD Edwards) typically costs 30-50% of Oracle's 22% annual maintenance fee, and covers custom code that Oracle's standard support does not. The support cost reduction service maps this decision systematically. Reference: Insurance company saving $2.8M/year through third-party support.

Phase 3: Governance, Controls, and Ongoing Compliance

Technical remediation and commercial optimisation address existing gaps. Phase 3 builds the internal controls that prevent those gaps from re-emerging — and that make your next Oracle audit a less significant event. The enterprises that handle Oracle audits most effectively are those with mature Oracle licence management programmes, not those that scramble to remediate in the weeks before Oracle arrives.

Oracle Licence Register

Maintain a living register of every Oracle licence your organisation holds — product, metric, quantity, CSI number, Order Form reference, and expiry date. This register should be updated at every Oracle procurement event, every infrastructure change that affects Oracle deployment, and at least annually through an internal compliance review. The register is your first line of defence in any Oracle audit: it allows you to immediately confirm what you hold before Oracle presents its claim.

Change Management Gate

The most common source of Oracle compliance drift is infrastructure changes made without Oracle licence impact assessment. Adding hosts to a VMware cluster, enabling Oracle database options for a development project, expanding Java SE deployments to a new business unit — each of these is an Oracle licensing event. Establish a formal change management gate that requires Oracle licence impact review before any infrastructure change that could affect Oracle software deployment scope. Connect your ITSM or CMDB to Oracle licensing review as a mandatory step, not an advisory one.

Internal Audit Cycle

Run an internal Oracle compliance review every twelve to eighteen months — using the same methodology Oracle's LMS team applies, not a simplified inventory scan. This means reviewing DBA_FEATURE_USAGE_STATISTICS, running USMM or equivalent on all Oracle Database instances, auditing Java SE installations against your employee count and Oracle's Employee Metric scope definition, and reviewing any ULA deployment counts against certification targets. The internal review identifies drift before Oracle does — and gives you the opportunity to remediate before an external audit arrives. Our internal Oracle licence audit guide covers the step-by-step process in detail.

Oracle Remediation Traps to Avoid

Oracle's account teams are present throughout the post-audit period — for licence repurchases, EA renewals, and cloud migration discussions. Their commercial interests do not align with your remediation objectives. Several common traps consistently appear in post-audit commercial negotiations:

• Accepting Oracle's compliance position as the remediation baseline. Oracle's audit count is almost always overstated. Accepting it as the basis for remediation licences means purchasing more than you need. Always conduct an independent count before entering licence repurchase negotiations.
• Buying licences to cover Oracle's claimed exposure rather than your actual exposure. The difference is typically 30-60%. Independent analysis of your actual deployment footprint identifies the genuine remediation requirement.
• Accepting a ULA or PULA as a "compliance solution." Oracle's account teams frequently propose ULAs as a way to resolve compliance gaps — the pitch is that you get unlimited deployment and your audit exposure goes away. In practice, a ULA entered under commercial pressure from an audit typically has unfavourable pricing, tight certification terms, and does not include the full product set you need. See the ULA guide for proper ULA evaluation criteria.
• Cloud migration as audit resolution. Oracle's GLAS team increasingly pairs compliance settlements with OCI or SaaS migration commitments. The cloud deal should be evaluated on its own merits — cloud economics, migration costs, operational impact — not as a mechanism to make an audit go away. The cloud advisory service evaluates OCI vs multicloud economics independently of Oracle's commercial pressure.
• Signing the remediation licence before resolving the technical gaps. Purchasing licences before completing technical remediation means paying for a larger footprint than you will actually end up with. Complete technical remediation first, quantify the residual gap, then purchase only what the remediated environment requires.

Preparing for the Next Oracle Audit

Enterprises that have been through an Oracle LMS audit can expect another engagement within three to five years — sometimes sooner if Oracle's account team identifies commercial opportunity or if an M&A event triggers a review. The enterprises best positioned for the next audit are those that have used the remediation period to build a defensible compliance position rather than simply purchasing their way through Oracle's current claim.

A defensible compliance position has three characteristics. First, your software deployment and licence entitlements match within a margin of five percent or less — no significant over-deployment, clearly documented licence registers for everything you run. Second, your infrastructure architecture minimises Oracle's measurement scope — Oracle workloads on dedicated or clearly defined infrastructure, with documented configurations that constrain cluster-wide licence claims. Third, your internal governance processes — change management gate, licence register, internal audit cycle — are operating and can demonstrate continuous compliance management rather than reactive scramble.

The compliance review service can be engaged on a retained basis — annual reviews that keep your Oracle compliance position current and give you an independent assessment before Oracle arrives, not after. This is the model used by the enterprises in our case study on PE Portfolio Cross-Company Optimisation — a programme that maintained compliance across twelve portfolio companies simultaneously, producing a 30% licence cost reduction while eliminating audit exposure across the group.

For an overview of the full Oracle audit process — from the initial LMS notification letter through measurement, findings, negotiation, and settlement — the Oracle Audit Guide and the Oracle Audit Timeline article provide the complete picture.