How does an Oracle audit start?
An Oracle audit starts with a formal notification letter from Oracle GLAS, the team formerly known as License Management Services, citing the audit clause in your Oracle Master Agreement. The letter names a scope, proposes a timeline, and usually asks you to run Oracle's measurement scripts and return the output. It arrives looking procedural and final, but almost everything in it is an opening position. The audit clause gives Oracle a right to verify, not a right to dictate every term of how that verification happens.
Most letters set a response window of 30 to 45 days. That number is real, but it is a starting point for a conversation about timing, not a deadline you must accept in silence. Acknowledging receipt, naming a single point of contact, and asking for clarity on scope are reasonable first steps that cost you nothing and buy you time.
Why is Oracle auditing you now?
Oracle is auditing you now because something changed that Oracle can see or infer, because the audit is also a sales channel. Analysts estimate that 20 to 30 percent of Oracle's on premises license revenue comes from audits, so a finding is not just a compliance exercise, it is a commercial event that can feed a ULA renewal, an OCI commitment or a Java subscription. Understanding that the audit is a negotiation dressed up as an inspection changes how you respond from day one. For the full list of prompts, see what triggers an Oracle audit.
What should you do in the first two weeks?
In the first two weeks you should assemble your contract, control your communications, and resist the urge to measure anything in a hurry. The single most valuable document is your signed Oracle Master Agreement with every ordering document, because the contract beats policy whenever the two disagree. Read the audit clause itself: it sets out notice, cooperation and timing, and it rarely says what a first letter implies it says.
Route every message through one named contact, agree a realistic timeline in writing, and do not run Oracle's scripts until you have reviewed what they collect. Running the scripts is a decision, not an obligation.
Controlling communication matters because casual answers to early questions become facts in the finding. A throwaway note that a workload sometimes moves across hosts can be enough for Oracle to assert a cluster wide virtualization claim. Keep answers accurate, scoped and considered.
What about the data Oracle asks for?
The data Oracle asks for usually comes from collection scripts, and that output should be reviewed before it ever leaves your building because the scripts can overcount across virtualization layers. A single virtual machine can pull an entire cluster into scope, and an option enabled by one click in Enterprise Manager can register as licensable usage. Reviewing the raw output, reconciling it against what is genuinely deployed, and submitting a reviewed data set is standard buyer side practice, not obstruction.
| Stage | Typical timing | Buyer move |
|---|---|---|
| Letter received | Day 0 | Acknowledge, name one contact |
| Scope and timeline | Days 1 to 10 | Negotiate both in writing |
| Measurement | Days 10 to 30 | Review script output, reconcile |
| Preliminary finding | After submission | Read as opening position |
What happens when the finding arrives?
When the preliminary finding arrives it will be inflated and priced at list, and that is by design. Independent line by line review of findings typically cuts claims 60 to 80 percent by correcting core counts, removing options never operationally used and dismantling cluster wide virtualization claims that rest on policy rather than contract. The number on the page is where the negotiation starts, not where it ends. To see how the rest of the process unfolds, read the full Oracle Audit Defense Guide, and avoid the early errors set out in the Oracle audit myths that cost money.
Download the Oracle Audit Defense Handbook for the full first response framework and the audit clause checklist. Get it from the white paper library.