What counts as audit evidence
Oracle audit evidence is broader than most customers assume. The obvious component is the measurement data: the output of the collection scripts that record deployed programs, feature usage flags, processor and core counts, and user accounts. But the evidentiary record extends well beyond the script files. It includes the entitlement documentation the customer produces to prove what it owns, the architecture and configuration data that reveals the virtualization topology, and, critically, the statements customer staff make in calls, emails, and interviews.
Each of these feeds the findings. A feature usage flag becomes a claim that an option must be licensed. A cluster topology becomes a soft partitioning argument. An email confirming that a tool was deployed becomes proof of use. A technician's offhand remark in a kickoff call that the team has been using a management pack becomes an admission Oracle quotes back in the findings report. The evidence is not just the data; it is everything the customer commits to the record, and the record is permanent.
This breadth is why evidence control is a discipline rather than a single action. It is not enough to review the script output if the same week a manager confirms exposure in an email or a technician volunteers usage in a call. The whole surface, data, documents, and statements, has to be managed as one record, which is the organising principle of the audit defence approach and the reason communication is funnelled through a single controlled channel.
Who supplies the evidence
The defining feature of an Oracle audit is that Oracle does not collect the evidence; the customer does. Oracle has no direct visibility into a private estate. It cannot see how many cores a server has, which options are enabled, or how many users access a database. It learns all of that only from what the customer runs and returns. This dependence is usually framed as the customer's obligation, but it is equally the customer's leverage: the party that supplies the evidence has substantial control over what the evidence shows.
Oracle cannot see your estate. It sees only what you hand it, which means the customer writes the first draft of the evidence and decides what reaches the record.
Recognising this reframes the audit from a search, in which Oracle uncovers hidden facts, to a submission, in which the customer chooses what to provide within the bounds of the contract. The choice is not whether to comply but how, and the how is where exposure is won or lost. Providing exactly what the audit clause requires, reviewed and in context, produces a different record from forwarding everything the moment it is requested. The principle of providing the required minimum, no more, is set out in full in the data minimisation guide, and it rests entirely on the fact that the customer is the source.
Why should you review evidence before you send it?
Because the customer supplies the evidence, the customer can read it first, and reading it first is the single highest value act in the audit. Review is not alteration, which would be both wrong and detectable; it is understanding what you are about to hand over and being ready to explain it. The script output is full of data points that look damning in isolation and benign in context: a feature flag set by a default tool behaviour, a high core count on a host where the database is pinned to a few cores, a long user list dominated by service and batch accounts rather than humans.
Each of those needs context attached before it leaves the building, because once it reaches Oracle uncontextualised, the customer is arguing against its own evidence. A flag with no explanation is read as deliberate use. A core count with no architecture note is read as full deployment. A user list with no breakdown is read as all Named User Plus. The review that supplies the missing context, performed with the rigour the script review guide describes, is what turns raw data into a defensible position rather than a confession.
Review also catches scope violations. Collection sometimes sweeps in servers, instances, or products outside the agreed perimeter, and reading the output against the scope boundary lets the customer withhold or query anything collected beyond what was agreed. The evidence that should never have been gathered is the easiest to exclude, but only if someone reads the files before they are sent. The customer who forwards output unread surrenders both the context and the scope challenge in a single click.
Reviewing before sending also resets the tempo of the audit in the customer's favour. Oracle's collection workflow is built for speed: run the scripts, return the output, move to findings. A customer that inserts a deliberate review step between collection and transmission slows that tempo to one it controls, and the slower tempo is almost always the cheaper one, because it is in the rushed handover that unexamined evidence does its damage. Taking the time to read every file is not obstruction and need not be adversarial; it is ordinary diligence over data the customer is contractually entitled to understand before it provides it. The audits that settle small are, almost without exception, the ones where someone read the output line by line before it left the building.
Evidence type, risk, and control
The table maps the main categories of evidence to their characteristic risk and the control that limits it. The pattern is consistent: every category is supplied by the customer, and every one is controllable.
| Evidence type | Characteristic risk | Control |
|---|---|---|
| Measurement output | Feature flags read as deliberate use | Run yourself, review every file, add context |
| Configuration data | Topology becomes a partitioning claim | Document architecture and boundaries first |
| Entitlement records | Gaps read as missing licences | Reconcile entitlements before producing them |
| Written statements | Emails become admissions | Single channel, reviewed before sending |
| Verbal statements | Offhand remarks become concessions | Brief staff, avoid unscripted answers |
Documenting scope and context
The mirror image of controlling Oracle's evidence is building your own. An audit produces two records: the one Oracle compiles to support its claim, and the one the customer keeps to support its defence. The defensive record documents what was provided, when, against which hosts, under what scope agreement, and with what context, and it is the evidence that resolves disputes about whether a finding rests on data the customer never actually submitted or on a server outside the agreed perimeter.
Good documentation also captures the context that explains the data. If a feature flag reflects a one time test, the record should note when and why. If a core count is constrained by a pinning configuration, the architecture note should establish it. If a user list includes service accounts, the breakdown should be on file. This context is far more persuasive when it is contemporaneous and documented than when it is asserted months later under settlement pressure, which is why the audit defence service builds the customer's record in parallel with Oracle's from the first day of the engagement.
Finally, the defensive record supports the findings challenge. When Oracle issues its claim, the customer's documentation is the basis for contesting each line: this flag was a test, this count is constrained, this account is not a user, this server was out of scope. Without that record the challenge is assertion against Oracle's data; with it, the challenge is evidence against evidence, which is a far stronger position and the one the audit defence white paper shows produces the largest reductions.
The buyer side view
Audit evidence is not something that happens to a customer; it is something the customer largely creates. The data Oracle relies on is data the customer runs, the documents are documents the customer produces, and the admissions are statements the customer's people make. That makes evidence control the most leveraged discipline in the entire audit, because it operates at the source rather than after the fact.
Treat every file, document, and statement as part of a permanent record, review everything before it leaves the building, provide only what scope requires, and keep your own parallel record of what you sent and why. Ground the discipline in the audit defence pillar, apply the collection rigour of the audit scripts guide, and hold the line on volume with the data minimisation guide.
Oracle audit evidence: frequently asked questions
Who provides the evidence in an Oracle audit?
The customer supplies the overwhelming majority of it. Oracle does not have direct visibility into your estate, so it relies on the data you run and return, the entitlement records you produce, and the statements your staff make. That dependence is also the customer's leverage, because controlling what is supplied controls what can be claimed.
Can I refuse to provide certain audit data?
You can and should limit what you provide to what the contract requires and the agreed scope covers. The audit clause defines Oracle's rights, and data outside that scope or beyond the contractual obligation can be withheld or queried. Refusing to volunteer unrequired data is a legitimate exercise of scope control, not obstruction.
Are verbal statements treated as audit evidence?
Yes. Casual admissions in kickoff calls or technical interviews, such as confirming a feature was used, can become part of the record Oracle relies on. Route communication through a single controlled channel and avoid unscripted concessions, because an offhand remark can do as much damage as a data file.