Oracle Java Audit Response: What to Do When You Receive an Audit Notice

The Oracle Java Audit: Soft Contact or Formal Notice?

Oracle's Java compliance process operates on a spectrum from informal outreach to formal audit. Understanding where you are on that spectrum shapes the urgency and nature of your response. Regardless of the form Oracle's initial contact takes, the fundamental principles of your response are the same: control the communication, gather your own data first, and do not make substantive disclosures without preparation.

Soft Audit — Informal Outreach

The most common form of initial contact is what is known in the industry as a "soft audit": an email or phone call from an Oracle account manager, renewal specialist, or "Java compliance" team member asking about your Java deployment. The language is collaborative and non-threatening. Do not be deceived by the tone. Oracle is gathering intelligence, and anything you share — the approximate number of servers, the Java versions you run, which applications depend on Oracle Java — becomes part of Oracle's dataset.

At the soft audit stage, the appropriate response is to acknowledge Oracle's contact through your designated single point of contact, request that all future correspondence be in writing, and make no substantive disclosures. You are not obligated to answer Oracle's questions at this stage.

Formal Audit Notice

A formal audit notice typically arrives as a written letter or email that cites the audit rights clause in your Oracle licence agreement and formally requests your cooperation in a "licence compliance review." This is a more serious communication. Your Oracle licence agreement likely does include audit rights — typically requiring you to provide access to your environment and deploy Oracle's collection tools — but those rights are not unlimited, and they come with procedural requirements that you can and should use to your advantage.

When you receive a formal audit notice, your first obligation is not to respond immediately with data. Your first obligation is to assemble the right team, understand the scope and basis of Oracle's request, and begin your own internal review.

Step 1: Centralise All Communication Immediately

The most damaging thing that can happen in the early stages of an Oracle Java audit is uncoordinated communication. If multiple people in your organisation are independently talking to Oracle — the IT manager who received the first email, the helpdesk person Oracle called, the procurement manager who happened to pick up the phone — Oracle builds a mosaic of inconsistent information that it can use to its advantage.

The moment you become aware of an Oracle Java compliance inquiry, implement a communication lockdown. Every member of your organisation must be instructed that all Oracle correspondence related to Java, licences, or compliance goes through a single designated point of contact. Typically, this is a senior member of your procurement or legal team. Everyone else — IT, development, operations, finance — should forward any Oracle contact to that person without responding.

This instruction should go out as an internal memo or email within hours of Oracle's first contact. It should be explicit and should name the designated contact. It should specify that even informal conversations with Oracle account managers about "reviewing your Java deployment" must be routed through the designated contact.

Step 2: Assemble Your Response Team

An Oracle Java audit is not an IT problem — it is a commercial and legal problem that happens to have a technical component. Your response team should reflect this. The core team typically includes a procurement or vendor management lead (who owns the Oracle relationship and the commercial response), a legal counsel or contracts manager (to review Oracle's audit rights and assess legal exposure), an IT or infrastructure lead (to conduct the internal Java inventory and work with Oracle's collection tools), and an independent Oracle licensing specialist if you have access to one.

The IT lead's role is specifically technical: run the internal Java inventory, review Oracle's proposed collection scripts, and produce the data that the commercial and legal team uses. The IT lead should not be communicating with Oracle directly about findings, compliance positions, or negotiating terms. The commercial and legal team owns all Oracle-facing communication.

If your organisation does not have internal Oracle licensing expertise, engaging an independent advisory firm is strongly recommended at this stage. The cost of advisory support is typically a small fraction of the difference between a well-negotiated and a poorly-negotiated Oracle Java audit outcome.

Step 3: Acknowledge Oracle's Contact — Nothing More

Acknowledging Oracle's contact is important — ignoring a formal audit notice is worse than responding poorly, because it allows Oracle to characterise your organisation as non-cooperative and to escalate to more aggressive communications. But the acknowledgement should be minimal and should not contain any substantive information about your Java deployment.

An appropriate acknowledgement says: you have received Oracle's communication, you are reviewing it and assembling the appropriate team, and you will respond with a substantive reply by a specified date. That date should give you enough time to complete your internal inventory — typically two to four weeks, though Oracle may push for a faster response. Your acknowledgement should also request that Oracle confirm the basis for the audit in writing — specifically, which provision of which agreement gives Oracle the audit right it is exercising.

Keep the acknowledgement to email. Do not have phone calls with Oracle about the substance of the audit at this stage. Phone calls are not documented, are easy to mischaracterise, and happen before you have your internal position established.

Step 4: Run Your Internal Java Inventory

Before you run Oracle's collection scripts and before you provide Oracle with any data about your estate, you need to know what your own data shows. The internal inventory is the most important single action you can take in an Oracle Java audit, and doing it before Oracle's scripts run gives you a critical advantage: you can see the data Oracle will see before Oracle sees it.

The internal inventory should cover every system in your estate — production, development, test, disaster recovery, containerised environments, and cloud deployments. For each system, identify whether Java is installed, which version, and — critically — which distribution. Oracle Java SE and OpenJDK produce similar but not identical version output. Confirm each installation's distribution affiliation independently, not just from the version string.

The inventory should also capture the application associated with each Java installation. Some applications — particularly legacy Oracle products — require a specific JDK that may not be replaceable. Knowing which installations can be migrated to OpenJDK before the audit data is submitted allows you to reduce your scope before Oracle gets its count.

Step 5: Review Oracle's Collection Scripts Before Running Them

When Oracle provides its collection scripts, you are entitled to review them before deployment. Oracle's audit scripts are typically delivered as a ZIP archive containing shell scripts, SQL scripts, and a deployment guide. They are, in most cases, read-only — they collect information but do not modify your systems. Verify this with your technical team before running them in production.

Review the scripts in a test environment first. Understand what data they collect, how they identify Oracle Java versus OpenJDK installations, and whether they capture any data beyond the Java discovery scope that Oracle requested. If the scripts collect data that goes beyond what is required for a Java-specific audit — for example, if they scan for Oracle Database or Oracle middleware installations — you have grounds to request a version of the scripts scoped specifically to Java.

Do not run Oracle's collection scripts in your production environment until your internal inventory is complete and your technical team has reviewed what Oracle's scripts will collect. The sequence matters: your data first, Oracle's data second.

Step 6: Remediate Before Submitting Data

One of the most underused opportunities in an Oracle Java audit is the period between the audit notice and the data submission. During this window, any Oracle Java installation that can be migrated to an OpenJDK alternative should be migrated. Every installation you remediate before submitting data is an installation that is not in Oracle's count.

Prioritise migrations that are straightforward: test and development environments where the JDK can be swapped directly, non-critical applications where the OpenJDK replacement can be validated quickly, and any environments where Oracle Java was installed but is not actively used. Document each migration with the date, the original installation details, and the replacement distribution.

You do not need to disclose the remediation to Oracle. You are simply ensuring that when Oracle's collection scripts run, the data they collect accurately reflects your current estate — which now includes fewer Oracle Java installations than it did before the audit notice arrived.

Step 7: Submit Data with a Covering Statement

When you submit data to Oracle's GLAS team, do not submit it without a covering statement. The covering statement should: identify what the data covers (systems, environments, dates of scan), describe the methodology used to produce the data, note any known limitations or exclusions, and state that any installations identified as OpenJDK or non-Oracle distributions have been excluded from the Oracle Java count.

The covering statement creates a documented record of your position at the time of data submission. It is the baseline against which you can challenge any of Oracle's assumptions in the subsequent audit report. Without a covering statement, Oracle's interpretation of your data is the only interpretation on record.

Step 8: Challenge Oracle's Audit Report

Oracle will process the submitted data and produce an audit report showing what it claims is your licence requirement and the gap versus what you have licensed. As discussed in our negotiation tactics guide, this report is an opening position and should be challenged on every assumption that can be contested with documented evidence.

Common grounds for challenge include: installations misclassified as Oracle Java that are actually OpenJDK, inflated employee counts based on HR data that includes exclusions you have not yet documented, double-counting of installations in virtualised or containerised environments, and retroactive claims for periods where Oracle's audit rights are legally limited or commercially negotiable.

Submit your challenge in writing, with the supporting evidence attached. Request that Oracle provide a revised audit report that reflects your corrections before any further commercial discussion. This establishes a clear record of which adjustments Oracle accepts and which it contests.

Mistakes That Significantly Worsen Your Position

The following mistakes are consistently observed in organisations responding to Oracle Java audits and consistently lead to worse outcomes:

• Not acknowledging Oracle's contact at all: Ignoring Oracle escalates the audit faster and removes your ability to control the pace. Always acknowledge, even if you are not ready to engage substantively.
• Sharing environment data in informal conversations: Any deployment information shared verbally or informally before your internal review is complete becomes part of Oracle's dataset and may be used to support a higher claim.
• Running Oracle's scripts before completing your internal inventory: Running Oracle's scripts first means you see the data at the same time Oracle does, removing your opportunity to identify and remediate issues before submission.
• Making payments before a written settlement is in place: Any payment to Oracle before a comprehensive written settlement is agreed — including "good faith" payments — can be interpreted as a partial admission of the full claimed liability.
• Allowing IT staff to manage the audit without commercial oversight: Technical staff understand Java environments but typically do not understand Oracle's commercial strategies. The audit response requires both technical accuracy and commercial discipline.

After the Response: Planning for What Comes Next

Responding to an Oracle Java audit is a process that unfolds over weeks or months, not days. The data submission and initial challenge phase is followed by a commercial negotiation phase that determines the financial outcome. Prepare for this early by building your commercial position — your migration plan, your headcount adjustments, your Q4 timing analysis — while the technical phase is still underway.

Oracle's support fees increase by 8% per year under standard support terms. Any settlement that results in a forward-looking Java SE subscription commitment should be evaluated on the basis of the full multi-year cost with 8% annual increases applied, not just the year-one headline price. The total cost of ownership calculation may materially change the attractiveness of different settlement structures.

Redress Compliance provides end-to-end Oracle Java audit defence support, from initial response through data collection, technical challenge, and commercial negotiation. We work exclusively on the buyer side with no commercial relationship with Oracle.