The evidence file that wins the audit.

Every Oracle audit comes down to a contest between two versions of your estate. There is Oracle's version, assembled from broad assumptions and priced at list, and there is the documented version, assembled from your own records. The side with the better evidence file sets the terms. Building that file is the central work of the response window, and it is the work that turns an alarming opening number into a defensible settlement.

What is the evidence file and why does it decide the audit?

The evidence file is the organised set of documents that lets you answer every finding with proof, and it decides the audit because a finding you can document is a finding you can reduce. Oracle's preliminary report arrives inflated at list price, built on the least favourable reading available. The only thing that moves it is evidence: the contract term that says otherwise, the architecture diagram that bounds the scope, the usage record that shows an option was never run. An assertion does not move a finding. A document does.

This is why an independent line by line review typically cuts a claim 60 to 80 percent. The reduction is not negotiation theatre. It is the result of meeting each inflated line with a record that proves the defensible figure. The evidence file is where those records live.

What belongs in the file?

Four kinds of record belong in the file, and each answers a different class of finding. Assemble them deliberately during the response window rather than scrambling for them once a number is in dispute.

• The contract layer: the Oracle Master Agreement, every ordering document, and any amendments. This is the source of truth for what you are entitled to and what rules actually bind you.
• The entitlement layer: a clean inventory of the licenses you own, by product, metric and quantity, reconciled against the contract layer.
• The deployment layer: where Oracle programs actually run, on what hardware, in what virtualization architecture, with the diagrams and configuration records that bound the scope.
• The usage layer: evidence for each option and management pack in question, showing whether it was ever meaningfully used, and failover records that speak to the disaster recovery 10 day rule.

Why does the contract sit at the top?

The contract sits at the top of the file because the policy document is not the contract, and contract language beats policy wherever the two disagree. Many of Oracle's largest findings rest on policy papers rather than on signed terms. The clearest example is virtualization: Oracle's partitioning policy does not recognise VMware, Hyper V or KVM as hard partitioning, so it claims licensing across an entire cluster. That claim lives in a policy document, and policy documents are often weaker than the agreement you actually signed.

When a finding rests on policy rather than on a term you signed, the contract in your evidence file is the answer. You read your own agreement, you identify where the claim has no contractual basis, and you hold Oracle to the paper rather than the policy. This is contract dependent, which is exactly why the contract belongs at the top of the file and why the first task in any defense is to read it closely.

How do you handle options and management packs?

You handle options and management packs by documenting actual usage, because the most common surprise in an audit is an option that was enabled accidentally and never operationally used. A single click in Enterprise Manager can register usage of Diagnostics Pack or Tuning Pack, and many options install by default. Oracle's collection scripts will report that detected usage, and the preliminary finding will price it at list as if it were deployed in earnest.

The usage layer of the evidence file answers this. For each detected feature, you assemble the record of whether it was ever meaningfully used, when it was disabled, and what business function, if any, it served. A feature that was touched once and never relied upon is not the same as a feature in production, and the evidence file is what makes that distinction visible and defensible.

What about virtualization and disaster recovery evidence?

Virtualization and disaster recovery evidence belong in the file because both are places where a finding inflates on assumption rather than fact. For virtualization, the architecture records bound the scope to what actually runs Oracle, against Oracle's cluster wide reading. For disaster recovery, failover records speak to the 10 day rule, which allows running Oracle programs on an unlicensed failover node for up to 10 separate days in a calendar year for testing or actual failover. Routine testing can quietly exceed that allowance, so tracking failover days and documenting them protects the standby environment from becoming an unexpected licensing requirement. Both are contract dependent, so the evidence is read alongside the agreement, not in isolation.

How should the file be organised for the negotiation?

The file should be organised so that every line in Oracle's finding maps to a document that answers it, because that mapping is what makes the negotiation calm and short. When Oracle raises a line, you do not argue. You point to the record. A file built this way also disciplines your own position, because a claim you cannot document is a claim you should not make either. The result is a defensible number that both sides can stand behind, reached faster and with less friction than a dispute conducted on assertions.

The evidence file is the work the response window exists for, so control the timeline first, covered in controlling the audit timeline, and let the file lead you toward the right exit, covered in the settlement paths out of an Oracle audit. The complete method sits in the Oracle audit defense guide.