Why review audit data before submitting it?
You review audit data before submitting it because the raw output is the opening position, and once it leaves your network it becomes the basis of Oracle's claim. Oracle's collection scripts produce feature usage and deployment data that, in a virtualized estate, can count the same workload across several layers and report options as in use when they were merely installed by default. Submitted unchecked, that data sets the finding at the highest possible number. Reviewed first, it becomes a record you can stand behind, and it is the foundation of the line by line review that typically reduces a claim by 60 to 80 percent. The wider method sits in the Oracle Audit Defense Guide.
What should you check in Oracle script output?
You should check four things in Oracle script output: feature usage against what is genuinely in use, processor counts against the core factor table, virtualization boundaries against your contract, and Named User Plus counts against the contractual minimums. Each is a place where the raw number tends to run high. The Enterprise Manager packs and database options are the most common surprise, because a single click can register Diagnostics Pack or Tuning Pack, and many options install by default, so the usage views show activity that no one chose. Treat each flagged line as a question, not a conclusion.
Build a reconciliation sheet. One row per flagged item, with columns for what the script reported, what your entitlement covers, what the contract says and what the real deployment is. The gaps are your negotiation.
How do you check the virtualization data?
You check the virtualization data by comparing the boundary Oracle's scripts assume against the boundary your contract actually supports. Oracle's partitioning policy does not recognise VMware, Hyper V or KVM as hard partitioning, so the scripts tend to assume every core in a cluster is licensable. That assumption rests on policy, not contract, and contract language beats policy. The review establishes the real boundary, the hosts that actually run Oracle, and documents it before the cluster wide number ever becomes the agreed number.
| Data set | What it tends to overstate | Reconcile against |
|---|---|---|
| Feature usage | Options installed but never used | Actual use and entitlements |
| Processor counts | Cores before the core factor | Core factor table |
| Virtualization | Cluster wide reach | Signed contract boundary |
| User counts | Named User Plus undercounts | Contractual minimums |
How do you document a correction?
You document a correction by recording, for each disputed line, the evidence that supports your position and the contract clause that backs it. A correction is only as strong as its paper trail, so a feature usage dispute needs the configuration evidence that shows the option was not in genuine use, and a virtualization dispute needs the host inventory that proves the boundary. This file is what turns a verbal objection into a defensible reduction. For how the data sits inside the wider engagement, see disputing options enabled but never used and avoiding the forced OCI commitment.
What is the next step?
The next step is to build the review into your audit response from day one, so no data set leaves the building until it has been reconciled. If a script has already run and you are unsure what the output really shows, an independent read of that data is where the savings begin. The Oracle Audit Defense Handbook gives you the reconciliation framework and the dispute templates to do it.
Download the Oracle Audit Defense Handbook for the data review checklist and the dispute templates. Get it from the white paper library.