What Data to Share and What to Withhold

What data do you have to share in an Oracle audit?

In an Oracle audit you have to share what the audit clause in your contract obliges, in the form it specifies, and review every dataset before it leaves your organisation. That single principle governs every decision about what to share and what to withhold. An audit is a negotiation dressed up as an inspection, and data is the currency of that negotiation. The preliminary finding arrives inflated at list price, and the data you provide either supports an inflated claim or contains it.

The instinct of many technical teams is to be transparent and helpful, to run whatever Oracle asks and send the results. That instinct, applied without review, is exactly how findings balloon. The disciplined alternative is not obstruction. It is precision. You give Oracle what the agreement requires, accurately and on time, and you do not give Oracle raw output, casual statements, or data the contract never obliged.

What does the contract actually oblige?

The contract sets the boundary, and the policy document does not. Cluster wide virtualization claims and options usage findings often rest on Oracle policy papers that are weaker than the signed agreement, and contract language beats policy. So the first task is to read your Oracle Master Agreement and the audit clause to understand precisely what you must provide, in what form, and within what timeline. Many audit requests reach beyond that boundary, and recognising the line is half the discipline.

Typical obligations cover deployment counts relevant to the licensed metrics, such as processor counts against the core factor table, or Named User Plus counts against minimums. What the contract rarely obliges is unfiltered access to every system, informal verbal confirmations, or raw tool output presented as fact. Routing all of this through one reviewing channel keeps the boundary intact, which is why the discipline pairs naturally with the single point of contact rule.

Why is Oracle script output reviewed before submission?

Oracle script output is reviewed before submission because the scripts can overcount across virtualization layers and report enabled options that were never operationally used. Running the scripts at all is a decision, not an obligation. When the scripts run, they can sweep an entire VMware cluster and report every core as if Oracle were deployed everywhere, even where it never ran. Submitting that raw output concedes the cluster wide claim before any negotiation has begun.

Options and management packs raise the same risk. A single Enterprise Manager click can enable Diagnostics Pack or Tuning Pack, and many options install by default, so a raw scan can show options usage that has no business value and was never intentionally adopted. Reviewing and reconciling the output to the contract, disabling what was enabled in error, and documenting non operational usage are what turn a raw scan into a defensible position. The mechanics of disputing the inflated cluster claim are covered in disputing cluster wide virtualization claims.

What can you legitimately withhold?

You can legitimately decline to provide data the contract does not require, and you can insist that everything you do provide is reviewed first. This is not concealment. It is the ordinary discipline of answering precisely what was asked, in writing, and no more. Where Oracle asks for data beyond the audit clause, the right move is to ask for the request in writing and to map it back to the agreement before responding.

Equally, you withhold the casual statement. Verbal confirmations on calls, helpful emails that concede usage, and speculative answers about future plans all become part of the record Oracle can rely on. Moving every exchange into writing through one channel removes the casual admission as a category. And under audit pressure, the temptation to resolve everything quickly with an unplanned unlimited agreement should be resisted, a trap explained in avoiding the panic ULA.

Share and withhold at a glance

A worked example

Consider an anonymized manufacturer running Oracle Database on a large VMware estate. Oracle scripts were run early and the raw output, sweeping the whole cluster, was about to be submitted. Reviewed first, the output was reconciled to the hosts where Oracle actually ran, and two management packs enabled by default were shown to be unused and were disabled.

Reviewing before sharing reduced the position by roughly 76 percent, within the 60 to 80 percent range a line by line review typically achieves. The figure was defended not by withholding what the contract required, but by refusing to submit raw output as if it were fact. This example is illustrative and anonymized, and outcomes depend on your estate, your contract and your evidence.

Your next step

Deciding what to share and what to withhold is a contract reading exercise as much as a technical one, and it is best done before any data moves. Our free audit defense guide walks through the data discipline step by step, alongside the wider sequence in the Oracle audit defense guide.