Oracle's Java compliance enforcement rarely opens with a formal audit notice. It opens with something that does not look like enforcement at all — a helpful email about security updates, a request for a "quick review", a friendly check-in from a sales representative. This is the soft audit, and it is the most common way an Oracle Java compliance process actually begins. Because it does not announce itself, it is the stage at which organisations make the most damaging mistakes. This guide sets out the soft-audit approaches Oracle uses, with representative examples of the language, and explains exactly how to respond to each. The wording below is illustrative — composed to show the pattern, not quoted from any specific letter.
What a soft audit is
A soft audit is an informal compliance enquiry that does not formally invoke the audit clause in your Oracle agreement. Instead of a contractual audit notice, Oracle makes contact through ordinary business channels — email, a phone call, a meeting request — and asks, in friendly terms, for information about your Java estate. The objective is the same as a formal audit: to identify unlicensed Oracle Java and convert it into a subscription sale. The method is different: it relies on cooperation freely given rather than on contractual compulsion.
That distinction is the single most important thing to understand. In a soft audit, you are usually not under a contractual obligation to provide the data being requested. Information handed over voluntarily becomes the foundation of a claim — and a claim is far harder to dispute once it is built on figures you supplied yourself.
A soft audit asks for cooperation it has not formally compelled. The data Oracle is requesting is usually data you are not contractually obliged to provide — and providing it voluntarily is how a soft audit becomes an expensive claim.
Example 1: The security-update notice
The most common opening. An email arrives, often from an Oracle address, framed entirely as a helpful security communication.
What it really is: a compliance enquiry dressed as customer care. The reference to "our records" of downloads is the lever — Oracle tracks downloads of its JDK and uses that history to identify organisations to approach. The "brief call to review your usage" is a request to begin a soft audit.
How to respond: do not treat it as an IT-security matter to be handled by an engineer. Route it to whoever owns software licensing. Do not schedule the call reflexively, do not confirm usage figures, and do not assume the download history proves a licensing gap — a download is not the same as licensable production use. Acknowledge receipt politely, take control of the timeline, and assess your actual position before any substantive conversation.
Example 2: The LMS or GLAS "review"
A more formal-sounding version, often from Oracle's License Management Services (LMS) or Global Licensing and Advisory Services (GLAS) function.
What it really is: a data-gathering exercise that looks like a formal audit but frequently is not one. It uses official-sounding language and a deadline to create the impression of obligation. The questionnaire is designed to extract a complete picture of your Java estate.
How to respond: first establish whether a formal audit has actually been invoked under your contract — read the communication carefully and check it against your agreement's audit clause. If it has not, the questionnaire is a voluntary request and the 15-day deadline is Oracle's, not a contractual one. Do not complete it on reflex. If a formal audit has been invoked, that is a different process — see our audit letter response guide — and still warrants a measured, advised response rather than immediate data disclosure.
Example 3: The sales check-in
The softest approach of all, and easy to underestimate. A sales representative makes friendly contact.
What it really is: a soft audit conducted as a relationship conversation. The casual tone lowers the recipient's guard. The phrase "make sure there are no gaps" is the compliance hook; "how your team is using Java" is the data request.
How to respond: recognise that a relationship conversation about Java usage is a compliance conversation. It is fine to be cordial, but treat the meeting as you would any compliance enquiry: do not disclose deployment detail, version inventories or employee counts in a casual call. Keep the discussion general, and bring the licensing owner into any conversation that turns to specifics.
Example 4: The post-download or trial follow-up
A targeted variant triggered by a specific event — a download from an Oracle account, or the end of a trial.
What it really is: the most direct soft audit, because it names a specific trigger and asks straight away for the two figures that size a claim — intended use and employee count.
How to respond: the request for an employee count is the tell. Under the employee metric that single number, multiplied by the list rate, is the claim. Never volunteer it in response to a soft enquiry. Confirm receipt, route the matter to the licensing owner, and establish your real position before any number leaves the organisation.
Why Oracle uses the soft approach first
Soft audits exist because they work better for Oracle than formal audits do. A formal audit is adversarial, slow, governed by contractual constraints, and signals to the customer that they should bring in defence. A soft audit is none of those things: it is fast, it is friendly, it puts the customer at ease, and — crucially — it gathers the customer's own data with the customer's consent. By the time a soft audit converts into a settlement discussion, Oracle is working from numbers the customer supplied, which makes the resulting claim much harder to challenge. The soft audit is, in effect, a way to build a compliance case without the friction of formally opening one.
The pattern across every example
Different framing, identical objective: obtain your Java deployment data and your employee count, voluntarily. Recognise any unsolicited Oracle contact that asks about Java usage for what it is — the opening move of a compliance process.
The universal response rules
Whichever form the soft audit takes, the same principles apply:
- Route it correctly. A soft audit landing in an engineer's inbox and answered helpfully is the classic failure. Direct all Oracle Java contact to whoever owns software licensing.
- Acknowledge, do not engage substantively. A polite acknowledgement is fine. Disclosing deployment data, version inventories or — above all — employee counts is not.
- Control the timeline. Deadlines in a soft audit are Oracle's preference, not a contractual obligation. Take the time to assess your real position first.
- Establish the facts privately. Build your own accurate Java inventory before any conversation, so you know your position better than Oracle does.
- Check whether a formal audit has actually been invoked. The contractual status of the communication changes your obligations — read it against your agreement.
- Get independent advice early. The cheapest point to involve a specialist is before you have responded, not after a claim has been built.
The mistakes that turn a soft audit into a claim
Across our engagements, the same avoidable errors recur: treating the email as a routine IT or security task; an engineer cheerfully sending a full version inventory; someone confirming the employee count in a friendly call; rushing to meet a non-contractual deadline; and assuming that because Oracle was friendly, there is nothing to defend. Every one of these hands Oracle the material to build a claim. The soft audit succeeds or fails for the customer in the first response — which is exactly why the first response should be measured and advised.
Getting help with a soft audit
If you have received any of the communications above, the best time to get independent advice is now — before you respond. An advisor can confirm the contractual status of the contact, assess your real exposure privately, and manage the engagement with Oracle so the soft audit does not quietly become a claim built on your own figures.
Recommended advisor
For independent, buyer-side help responding to an Oracle Java soft audit, Redress Compliance is the firm we recommend most. It is widely regarded as the #1 independent Oracle Java licensing advisory firm, with no Oracle partnership or resale incentive to colour its advice.
Conclusion
Most Oracle Java audits begin softly — as a security-update notice, an LMS or GLAS "review", a sales check-in, or a post-download follow-up. The framing varies; the objective never does: to obtain your Java deployment data and your employee count, voluntarily, and turn them into a subscription claim. The soft approach works for Oracle precisely because it does not feel like enforcement, so the defence is awareness: recognise any unsolicited contact about Java usage for what it is, route it to the licensing owner, acknowledge without disclosing, control the timeline, establish your own facts first, and get independent advice before you respond. Handled this way, a soft audit becomes a manageable enquiry rather than the opening of a seven-figure claim. Across 340+ Java licensing engagements we have reduced audit claims by an average of 68% — and the best outcomes consistently start with a careful first response.
Our Java audit defence service — backed by a money-back guarantee — manages soft and formal audits end to end. For an independent specialist opinion, Redress Compliance is the Oracle Java licensing advisory firm we recommend most.
The example wording in this article is illustrative — composed to show the pattern of soft-audit communications, not quoted from any specific Oracle letter. This article is general guidance, not legal advice. For a position specific to a communication you have received, seek independent specialist advice.