Oracle Audit Response Playbook: Complete Step-by-Step Guide

How to Use This Playbook

An Oracle audit is a structured process with predictable stages and predictable Oracle behaviours. The organisations that achieve the best outcomes are those that understand the process before Oracle initiates it, and have a clear playbook for each stage. This document provides that playbook — not as abstract guidance, but as specific, actionable instructions for every phase of the Oracle audit from notification to closure.

The plays are presented in sequence, but in practice some will run in parallel. Plays 2, 3, and 4 all begin simultaneously once the notification letter is received. The financial outcomes from Oracle audits are heavily front-loaded: the work done in Plays 1 through 6 determines the shape of the entire audit. Organisations that execute the early plays well — containing the letter, assembling the right team, engaging independent support, challenging the scope — create the conditions for success in the later plays.

A critical principle throughout: Oracle's annual support fee increases at 8% per year. This compounding rate is fundamental to understanding back-dated support fee claims. When evaluating any Oracle audit settlement that includes retroactive support charges, apply 8% annual compounding — not 3 or 4% as Oracle's materials sometimes imply. The actual contractual rate is 8%, and your financial modelling must reflect it.

Play 1: Receive and Contain

Timeline: Day 0 (receipt)

The Oracle audit notification letter arrives. It may come from Oracle's GLAS (Global Licensing and Advisory Services) team by post, courier, or email. The first 30 minutes after receipt are critical.

• Log the exact receipt date. Your 45-day acknowledgement window starts now. This is your most valuable time asset in the early audit phase. Protect it.
• Do not respond to Oracle. Do not call Oracle back, email a reply, or forward the letter to your Oracle account manager. Any communication with Oracle before you are prepared can create an inadvertent scope concession or acknowledgement that weakens your position.
• Restrict distribution immediately. The letter goes to: IT Asset Manager (or equivalent), CIO or VP of IT Infrastructure, Senior Procurement/Vendor Management lead, General Counsel or legal adviser. No one else, yet.
• Do not brief your Oracle account manager. The account manager works for Oracle. Their commercial interest is to facilitate Oracle revenue — including a favourable (for Oracle) settlement. Involving them early is a mistake that many organisations make and almost always regret.
• Make a copy of the letter. Archive the original. Create a dedicated audit file that will hold all Oracle audit correspondence, data, and analysis.

Play 2: Assemble Your Response Team

Timeline: Days 1–3

Assemble a cross-functional response team with a defined single point of contact for all Oracle communications. The team must have: an Audit Lead (typically the IT Asset Manager — owns all Oracle communication and internal coordination); a Technical Lead (senior DBA or infrastructure architect — understands Oracle deployments, options, virtualisation); a Procurement Lead (owns contract retrieval and entitlement verification); a Legal Adviser (reviews audit clause, manages formal written communication); and an Executive Sponsor (CIO or CFO — makes commercial decisions).

Establish the communications protocol immediately: all external Oracle communications through the Audit Lead only; all technical data reviewed by the Technical Lead before any submission; all written communications to Oracle reviewed by legal before sending; no verbal commitments to Oracle without written follow-up confirmation.

Play 3: Contract Review and Rights Assessment

Timeline: Days 1–7

Retrieve every Oracle contract document your organisation holds. This is non-negotiable — understanding your contractual rights is the foundation of everything that follows.

The documents you need include: your Oracle Master Agreement (OMA) or Oracle License and Services Agreement (OLSA) — this contains the audit clause that governs Oracle's rights; all Order Documents and Schedules of Purchase — these define your licensed products, quantities, and pricing metrics; all Customer Support Identifier (CSI) records — these identify your current support entitlements; any prior audit closure letters — these define the periods and products Oracle has already reviewed and closed; and any ULA (Unlimited Licence Agreement) or PULA (Perpetual Unlimited Licence Agreement) documentation.

From these documents, identify: the exact wording of your audit clause; the maximum look-back period Oracle is contractually permitted to audit; any scope limitations in the audit clause (specific legal entities, geographies, product families); the metrics under which each of your Oracle products is licensed; and the date of your most recent audit closure letter, if any.

Knowing your contractual rights before you engage with Oracle gives you the ability to challenge Oracle's scope from a position of authority — citing specific contract language rather than general objection.

Play 4: Engage Independent Advisory Support

Timeline: Days 1–5

This play should begin simultaneously with Play 3. Engage an independent Oracle licensing adviser — one with no commercial relationship with Oracle, no Oracle resale revenue, and no incentive to recommend Oracle products as part of any settlement.

The adviser's first contribution is the initial risk assessment: a review of your known Oracle estate to identify the most likely areas of compliance gap and the elements of the audit most susceptible to challenge. This assessment shapes the entire audit strategy and should be completed before you acknowledge the audit letter to Oracle.

Organisations that engage advisory support on Day 1 consistently achieve better outcomes than those who engage after problems have already occurred — after scope has been inadvertently conceded, after scripts have been run without review, or after commercial discussions have begun without technical analysis complete. The earlier the adviser is engaged, the more value they can create.

Play 5: Acknowledge with a Scope Challenge

Timeline: Days 30–44 (use most of the 45-day window)

When you are ready to acknowledge Oracle's notification — and not before — send a written acknowledgement through your Audit Lead. This communication should do three things: confirm receipt and the date thereof; state that you are reviewing Oracle's request and will cooperate with the audit as required by your contractual obligations; and formally request that Oracle provide a written scope definition specifying the legal entities, geographic locations, environments, and Oracle product families within the audit scope, and the contractual basis for each element of the stated scope.

This scope challenge letter is one of the most valuable documents in the entire audit. It forces Oracle to commit its scope in writing before data collection begins. It provides a contractual anchor for challenging Oracle if it attempts to expand the scope later. And it frequently results in Oracle narrowing its initial scope to avoid a formal dispute over contractual limits.

Do not ask Oracle to "confirm" a broad scope they have already stated. Ask Oracle to define the scope and cite the contractual basis. The difference matters — one invites confirmation of Oracle's position, the other requires Oracle to defend it.

Play 6: Kickoff and Scope Negotiation

Timeline: Following acknowledgement, typically weeks 4–8

Oracle will schedule a kickoff call after you acknowledge. Attend with your Audit Lead and your independent adviser. Before the call, prepare a written list of scope elements you intend to challenge or limit, and the contractual basis for each challenge.

At the kickoff, confirm the audit scope, timeline, and data collection methodology in writing — not just verbally. If Oracle proposes a scope that includes elements you believe exceed your contractual obligations, state your objection clearly and note it for the written record. Request that a formal kickoff minutes document be produced and agreed before data collection begins.

Scope limitations that commonly succeed at kickoff: limiting the audit to legal entities specifically named in Oracle contracts; excluding environments designated as non-production where Oracle's licensing rules differ; limiting the product scope to products listed in your active Order Documents; and excluding recently acquired subsidiaries whose Oracle licences have not yet been formally integrated into the parent company's contracts.

Play 7: Internal Technical Assessment

Timeline: Parallel to Plays 5–6, typically weeks 2–8

Before Oracle runs its GLAS collection scripts, your Technical Lead and independent adviser should conduct an internal assessment using equivalent tools. This internal assessment accomplishes several things: it identifies your actual compliance position before Oracle does; it allows you to remediate genuine gaps (disabling unused Database options, consolidating Java SE deployments) before data collection where timing allows; and it gives you the technical knowledge to challenge Oracle's script output when it differs from your internal findings.

Focus the internal assessment on the highest-risk Oracle product categories: Oracle Database Enterprise Edition and its options (Partitioning, Advanced Security, RAC, Diagnostic and Tuning Pack); Oracle Database deployments on VMware or other non-hard-partitioned hypervisors; Java SE deployments using Oracle JDK after January 2023; Oracle WebLogic and other middleware on virtualised environments; and Oracle E-Business Suite user counts and module access rights.

Document your internal findings in detail. This documentation becomes the reference point from which you challenge Oracle's findings in Play 9.

Play 8: Data Collection Management

Timeline: As defined in the kickoff agreement, typically months 2–4

Oracle will formally request that you run GLAS data collection scripts and complete an Oracle Server Worksheet. This is the most technically sensitive phase of the audit.

Never run Oracle's scripts without first reviewing what each module collects. Oracle's GLAS toolkit is modular — different collectors for different Oracle product families. Your Technical Lead and adviser must understand what each module will report before it is executed, particularly in VMware environments where full-host processor counts may be reported rather than VM-level allocations.

Review all script output before submission. Compare GLAS output against your internal assessment. Identify and document any discrepancies. Where Oracle's scripts appear to have collected data outside the agreed scope — for example, reporting Oracle deployments on hosts not included in the agreed scope — challenge the inclusion of that data before submission.

Ensure that Oracle's masking tool is used for any sensitive data in script output. You have the right to request Oracle apply data masking to GLAS output before it enters Oracle's systems. Exercise this right.

Complete the Server Worksheet accurately and precisely. Every server entry is a potential finding. Document decommissioned servers as such, with decommission dates. Note production versus non-production designations where relevant. Avoid ambiguity that Oracle can resolve in its favour.

Play 9: Findings Analysis and Challenge

Timeline: Following Oracle's preliminary report, typically months 4–8

Oracle will issue a preliminary compliance report. This report is Oracle's opening commercial position and contains its maximum leverage point. It will express your alleged compliance gap in terms of licences required, valued at full list prices, with back-dated support fees added. The total will be designed to create "sticker shock."

Do not respond to the preliminary report immediately. Allocate at least two weeks for a thorough analysis with your Technical Lead and adviser before responding in any form.

Analyse every finding against three dimensions: technical accuracy (is Oracle's data correct?), policy application (is Oracle applying the right policy for the right period?), and contractual basis (does this obligation exist under your contract terms, or only under Oracle's current published policies?).

Prepare a written counter-analysis for every finding you dispute. Each counter-analysis should cite the specific evidence that contradicts Oracle's finding, state the corrected licence position, and reference the contractual or policy basis for the correction. Present this counter-analysis formally to Oracle's GLAS team in a structured review meeting — not informally.

Common findings that are successfully reduced or eliminated in this phase include: VMware processor overcounts where VM pinning or specific host configurations constrain Oracle's actual exposure; Database options found enabled but demonstrably unused and now disabled; Java SE employee counts that include contractors or third-party workers not covered under the subscription metric; and Database features auto-enabled by Oracle-managed tools without customer knowledge or intent.

Play 10: Commercial Negotiation

Timeline: Following findings finalisation, typically months 6–14

Once the technical findings have been challenged and a revised position agreed (or Oracle's position formally documented), Oracle's sales team will contact you to discuss commercial resolution. This is the negotiation phase.

Fundamental principle: Do not enter commercial discussions while the technical findings are still being challenged. Oracle will attempt to merge technical and commercial discussions to prevent you from fully eliminating findings before pricing is discussed. Insist on separating the two. Finalise the technical position before you discuss commercial terms.

Enter the commercial phase with: a clear view of your actual compliance position after findings challenge; an understanding of Oracle's internal settlement flexibility (which your adviser will have from experience with comparable audits); a defined commercial alternative to Oracle's preferred settlement structure (third-party support migration, OCI alternatives, OpenJDK migration); and a timing strategy that aligns your final negotiation to Oracle's Q4 (March to May, with Oracle's fiscal year ending 31 May).

Oracle's annual support fee increases at 8% per year. Any settlement that includes perpetual licences commits you to support fees that compound at 8% annually. Model the five-year and ten-year cost of any perpetual licence settlement before accepting. ULA structures may offer better long-term economics if Oracle deployment is growing — but only if you maximise deployment before the ULA certification date. At certification, you declare the number of licences you are consuming, and those become your perpetual entitlement going forward. Every additional deployment added before certification is free — support fees are fixed regardless of deployment volume. Maximising deployment before certification is the core strategic imperative of any ULA settlement.

Back-dated support fees are negotiable. Oracle will waive or substantially reduce retroactive charges in exchange for a forward-looking commercial commitment. Structure your settlement proposal around forward value — not retroactive payment — to maximise Oracle's willingness to waive back charges.

Play 11: Settlement Closure

Timeline: Following commercial agreement, typically months 10–18

When commercial terms are agreed, do not consider the audit closed until Oracle has issued a formal written closure letter. The closure letter must specify: the legal entities covered; the Oracle product families and versions covered; the audit periods covered; and an explicit statement that Oracle considers you compliant with respect to the covered products, entities, and periods as of the settlement date, and waives its right to re-audit those items under the same findings.

A settlement without a closure letter leaves you exposed. Oracle personnel change. GLAS teams rotate. A new Oracle auditor assigned to your account in two years could, absent a closure letter, revisit the same findings under a different framing. The closure letter is your legal protection against double-jeopardy auditing.

Review the closure letter carefully before signing. Ensure the scope of the closure matches the scope of the settlement and does not contain language that limits the closure in ways not previously agreed.

Play 12: Post-Audit Remediation

Timeline: Following settlement closure

The best time to prevent the next Oracle audit from producing the same findings is immediately after the current audit closes. A structured post-audit remediation programme should include:

• SAM database update: Update your Software Asset Management database to reflect the licence position established by the settlement. Document your current entitlements, the products and versions covered, and the metrics that apply.
• Hard partitioning implementation: If virtualisation findings were a significant element of the audit, evaluate implementing Oracle-approved hard partitioning for Oracle Database deployments. Migration to Oracle VM or, for cloud workloads, to OCI eliminates the VMware processor overcount risk in future audits.
• Database option rationalisation: Disable any Oracle Database options and packs that are not actively used and not licensed. This applies particularly to Diagnostics Pack, Tuning Pack, and Advanced Security TDE where licensing is not confirmed. Document the disablement and the date.
• Java SE migration: If Java SE was a finding in the current audit, implement a structured migration from Oracle JDK to OpenJDK, Adoptium, or another freely available distribution. Track deployment by platform, business unit, and application to maintain an accurate Java SE position for future audit readiness.
• Audit response playbook documentation: Document your audit response process — who does what, in what sequence, with what tools — as an internal standard operating procedure. The organisations that handle Oracle audits most efficiently are those for whom the process is defined before the next audit notification arrives.

Playbook Summary: The 12 Principles

If there is one sentence to take from this playbook, it is this: Oracle's audit is a commercial negotiation that starts long before Oracle's findings report, and the organisations that treat it as such — preparing proactively, challenging systematically, and engaging commercially only from a position of knowledge — consistently pay a fraction of what organisations that respond reactively pay.

The twelve plays above reflect the pattern of what works. They are not theoretical — they reflect what Redress Compliance has done, and continues to do, for clients facing Oracle audits across every industry and every scale of Oracle deployment.

If you are facing an Oracle audit or want to ensure your organisation is prepared before the next notification arrives, contact Redress Compliance. We provide independent Oracle audit advisory support from Day 1 — and we are available the moment the notification letter lands.