The data stage is where a Java audit is won or lost. Oracle asks for a wide set of information, and buyers often hand over all of it on the assumption that cooperation equals goodwill. The truth is that much of what is requested goes beyond any contractual obligation, and every extra piece of data becomes evidence for a larger claim. This article sets out what Oracle typically asks for, what you are genuinely obliged to provide, and what to withhold.
It sits within the defense framework in the Java Audit Survival Guide.
What Oracle typically asks for
A Java audit data request usually reaches for several categories at once. A full employee headcount, often global. A list of contractors and temporary workers. Deployment data showing where Java is installed across desktops, servers, and cloud. The output of a discovery or audit script. Download records and update history. And sometimes interviews with technical staff. Presented together, the list looks routine. Read individually, much of it is optional and some of it is harmful to volunteer.
What you are obliged to provide
Your obligations are defined by your agreement, not by the request. In most cases you are obliged to provide reasonable evidence relevant to the specific entitlements you hold, within a defined scope and timeframe. You are generally not obliged to run Oracle supplied scripts, to provide global data when the scope is narrower, or to volunteer interpretation of your own environment. The first task is always to read the audit clause and answer only against it. For how to bound the scope, read scoping an Oracle Java audit down to what matters.
What to withhold or narrow
Several common requests should be withheld, narrowed, or met only after careful review. Do not run and return the output of an Oracle discovery script. Do not provide a raw global headcount when scope or entity boundaries reduce the relevant population. Do not volunteer download or update history that Oracle has not specifically and contractually requested. Do not offer commentary on which workloads need Oracle Java SE. And do not let technical staff sit unprepared interviews where an offhand answer becomes a finding.
| Oracle asks for | Provide | Withhold or narrow |
|---|---|---|
| Employee headcount | Defensible in scope number | Raw global count |
| Contractor lists | Verified, deduplicated figures | Counts double counted with payroll |
| Script output | Nothing by default | Raw script results |
| Download history | Only if contractually required | Volunteered update records |
| Staff interviews | Prepared, single channel | Unprepared technical chats |
Why the script is the line that matters most
Of everything Oracle requests, the discovery script is the most consequential to withhold. Its output is raw, uncontextualised data that Oracle interprets to maximise the claim, and once returned it is almost impossible to walk back. There is rarely a contractual duty to run it simply because it was sent. Running it blindly is among the fastest ways to inflate exposure. Provide your own verified figures instead, on your terms.
The counted population is the prize
Behind every data request is the same target, the counted population, because the claim is roughly employee count times list rate times discount. A raw global headcount that ignores entity boundaries, divested units, and contractors double counted with payroll inflates the most important input. Provide a verified, deduplicated, in scope number, and you defend the line that moves the claim most.
Indicative worked example. An insurer faced a data request for its full global headcount and the output of a discovery script. It declined the script, provided a verified in scope population that excluded a separately licensed subsidiary and removed contractors already counted in payroll, and supplied evidence that a large server tier ran a free OpenJDK distribution. The data it withheld would have supported a far larger claim than the data it provided. Figures are indicative.
Cooperate on your terms
Withholding is not stonewalling. It is answering precisely against your obligations rather than against Oracle’s wish list. Cooperate fully on what the contract requires, decline what it does not, and verify everything before it leaves the building. For the earlier moves that set this up, read how to respond to an Oracle Java soft audit email.
Read the obligation before the request
Every data decision should start with your agreement, not with the email in front of you. The audit or verification clause defines the scope of what Oracle may examine, the notice it must give, and the standard of evidence it can require. Most clauses are narrower than the request issued under them. When you measure each ask against the clause, a large share of the request often turns out to be optional. Providing against the obligation rather than against the wish list is the difference between a bounded exercise and an open ended one.
Provide verified, not raw
Where you do provide data, provide it verified and contextualised, never raw. A raw headcount export includes everyone the system holds, including contractors double counted with payroll, employees of out of scope entities, and people in divisions that have left the group. A raw script output includes every trace of Java, including the free OpenJDK distributions that carry no Oracle obligation. Raw data is interpreted by Oracle to maximise the claim. Verified data, prepared by you and accompanied by your own explanation, defends the number. The work of verifying before sending is the work of the defense.
The interview risk
Requests for interviews or calls with technical staff are easy to underestimate. An engineer answering honestly about how the team uses Java can volunteer detail that becomes a finding, simply because they do not see the commercial frame. Where interviews happen, route them through the single owner, prepare the participants, and keep answers within the agreed scope. The goal is not to conceal anything, it is to ensure that informal recollection does not become evidence in a process where every word is weighed.
Download and update history
Oracle may ask for, or independently reference, records of Java downloads and update activity. This is sensitive because download history is used to argue that Oracle Java SE was in use and patched under an Oracle entitlement. Do not volunteer this history. Where it is contractually required, provide it with context that distinguishes Oracle Java SE from free OpenJDK distributions and that reflects when usage actually started and stopped. Unexplained download records left to Oracle’s interpretation are among the easiest ways for a claim to grow.
Cooperation that protects the number
None of this is about refusing to engage. A buyer that stonewalls invites a harder line and loses goodwill that is useful at settlement. The discipline is precision. Provide exactly what the contract obliges, verified and explained. Decline or narrow what it does not. Withhold the script output, the raw global headcount, the volunteered download history, and the unprepared interview. The result is a cooperative process that nonetheless protects the counted population, which is the input that moves the claim most. For how to narrow the overall scope around that population, read scoping an Oracle Java audit down to what matters.
The cost of over disclosure
Over disclosure is the most common and most expensive mistake at the data stage. Every extra figure, every volunteered environment detail, every unrequested record becomes part of the evidence base for the claim, and none of it can be easily withdrawn once sent. Buyers over disclose because it feels cooperative and because no single piece of data seems harmful on its own. In aggregate, though, an over disclosed estate supports a much larger claim than a precisely answered one. The discipline is to give exactly what is asked and obliged, and not one data point more.
Build a single, verified data set
Rather than answering requests piecemeal, build one verified data set internally that represents your true, in scope position, and respond from it. This set should reflect the contracting entity, a deduplicated population, the workloads that genuinely run Oracle Java SE, and the bounded time window. Answering from a single prepared source keeps your responses consistent, prevents contradictory figures from leaking out of different teams, and ensures that everything you provide has already been checked. Consistency is itself a defense, because contradictory numbers invite Oracle to assume the higher one.
When to say no, and how
Declining a request is a normal and legitimate part of an audit when the request exceeds your obligation. The way to decline is calm and specific. Reference the audit clause, state what you are providing against it, and explain that the additional request falls outside the agreed scope. You are not refusing to comply, you are complying with the contract as written. A clear, contract grounded no is far stronger than silence or than a reluctant yes, and it sets a boundary Oracle must justify crossing.
Keep a record of every exchange
Maintain a clear log of every request Oracle makes and every response you give, with dates and the name of the single owner who handled it. This record does several jobs at once. It keeps your responses consistent, it documents that you cooperated with what the contract required, and it shows exactly where you drew the line and why. In a process that may run for months and reach back three years, memory is unreliable and a contemporaneous record is authoritative. The log is also a discipline in itself, because knowing every exchange is recorded discourages the casual reply that inflates a claim.
Align the data with your scope
The data you provide should match the scope you have agreed, no broader. If scope is limited to the contracting entity and a defined period, the population and deployment data should reflect only that entity and that window, not the whole group across all time. Buyers undermine good scoping by then handing over data that quietly exceeds it, which invites Oracle to argue the scope should expand to match. Keep the data and the scope in lockstep, and you preserve the narrow base that protects the counted population and, with it, the size of the claim.
Precision is the defense
The data stage rewards precision above all. Provide exactly what the contract obliges, verified and explained. Withhold the script output, the raw global headcount, the volunteered download history, and the unprepared interview. Keep the data aligned with the agreed scope, log every exchange, and answer from a single prepared data set. Done this way, the data stage produces a small, defensible base rather than a broad evidence trail Oracle can build on. The buyer who is precise pays for what they use. The buyer who is generous with data pays for assumptions they could have prevented.
Next step. Download the Oracle Java Audit Survival Guide for the full data request checklist marking what to provide and what to withhold. We also work on a Fixed Fee from $18,000 or a Gainshare share of verified savings or avoided exposure, with zero retainer and no risk to you.