Who runs the audit, and under what authority
Oracle's compliance reviews are conducted by its License Management Services function, which in recent years has been folded into the Global Licensing and Advisory Services, or GLAS, organisation. Sometimes an external audit firm is engaged to run the data collection on Oracle's behalf. The name on the letterhead changes little: the process and the customer's contractual rights are the same, and the audit derives its authority from the audit clause in the customer's agreement, which is examined in the audit defence pillar guide.
Understanding that the auditor is a commercial party with a revenue interest, not a neutral assessor, frames everything that follows. The Oracle LMS audit process is designed to produce a defensible claim, and the data and interpretation that build that claim are both contestable. The customer that internalises this engages with each phase as a negotiation rather than a compliance formality.
Notification and scoping
The audit begins with a formal notification letter invoking the audit clause. This letter sets the clock running and frequently proposes a scope, a timetable, and a kickoff meeting. The customer's first moves here are decisive and are treated in detail in the audit notification response guide: acknowledge professionally, route the matter through a single controlled channel, and begin reading the relevant contracts before agreeing to anything.
Scoping then defines which products, which legal entities, and which time period the audit covers. This is a phase the customer should actively shape rather than accept. The audit should be bound to the products and entities the contract actually covers and to a reasonable timetable, not to whatever Oracle proposes. A scope agreed carelessly lets the data collection wander into areas the audit had no business examining.
| Phase | Oracle's activity | Customer's primary move |
|---|---|---|
| Notification | Issues audit letter | Acknowledge, centralise, read contracts |
| Scoping | Proposes products and entities | Bound scope to the contract |
| Data collection | Runs scripts and questionnaires | Validate every output first |
| Analysis | Interprets the data | Track and challenge assumptions |
| Findings | Issues draft claim | Rebut against definitions |
| Settlement | Proposes resolution | Negotiate on prepared evidence |
Data collection: the decisive phase
Data collection is where the audit is effectively won or lost, because every finding is built from the data the customer provides. Oracle typically supplies measurement scripts that collect deployment information from databases and servers, alongside questionnaires capturing usage and architecture. The temptation is to treat this as a clerical task and have IT run the scripts and return the output quickly. That instinct surrenders the most important phase of the audit.
The audit is decided in the data phase. By the time the findings arrive, the facts are already fixed, and you are arguing about a foundation you let the other side pour.
The disciplined approach is to understand what each script measures, run it in a controlled environment, and validate every output against the customer's own inventory before anything is submitted. Raw output routinely contains decommissioned systems, stale entries, misread configurations, and test environments that inflate apparent deployment. This is the practice of data minimisation: provide accurate, validated, in scope data and nothing unnecessary or unverified.
Analysis and findings
Once Oracle has the data it applies its own analysis, mapping deployment to entitlement and producing a draft findings report. This is where interpretation enters, and interpretation is contestable. A finding that an option is in use, that a cluster exposes a certain core count, or that a user population exceeds a minimum all rest on readings of the contract definitions that the customer can challenge. The largest findings are usually enabled database options, examined in the database options audit guide, and virtualization exposure.
The customer that tracked the assumptions feeding the analysis, and that holds its own validated count, can meet the draft findings with a structured rebuttal rather than a defensive scramble. Each contested finding is addressed against the contract's own definitions, and each genuine gap is acknowledged precisely so the argument stays credible. This is the moment the earlier discipline pays off.
Settlement
An Oracle audit rarely ends with a plain invoice. It ends with a negotiation, and Oracle's preferred resolution is frequently a forward looking purchase, new licences, a cloud subscription, or a Unlimited License Agreement, that converts the gap into future revenue rather than a one off penalty. The customer that arrives with a validated position can separate real gaps from contested findings, resolve the real gaps deliberately, and evaluate any forward offer on its merits instead of accepting it under pressure.
The settlement is the payoff for everything that came before. A customer that controlled the notification, bounded the scope, validated the data, and rebutted the analysis arrives here with leverage and a credible number. A customer that cooperated passively arrives with whatever the findings produced and little ground to stand on. For an engagement that runs this process end to end, see the Oracle audit defence service and the audit defence white paper.
The buyer side view
The Oracle LMS audit process is predictable, and that predictability is the customer's advantage. The leverage concentrates early, in the notification, scoping, and data collection phases, long before the findings that most customers treat as the main event. The customer that engages those early phases deliberately, validates its own data, and arrives at settlement with a defensible position routinely reduces the claim by a wide margin.
Treat every phase as a negotiation conducted on your own evidence, anchor each finding in the contract definitions, and begin building your position from the first letter. Read the audit defence pillar for the full lifecycle, the notification response guide for the opening moves, and the data minimisation guide for the decisive phase.
Oracle LMS audit process: frequently asked questions
What are the stages of an Oracle LMS audit?
An Oracle LMS audit moves through notification, scoping, data collection, Oracle's analysis, a draft findings report, and settlement. Notification and scoping set the boundaries, data collection produces the facts, and settlement is a negotiation. The data collection phase is the most decisive, because every finding is built from the data the customer provides.
Who runs an Oracle audit?
Oracle's compliance reviews are run by its License Management Services function, now part of the Global Licensing and Advisory Services organisation, sometimes with an external audit firm. Whoever conducts it, the process and the customer's contractual rights are the same, and the audit must proceed within the audit clause in the customer's agreement.
How long does the Oracle LMS audit process take?
Most Oracle LMS audits run several months from notification to settlement, and a large or contested estate can take a year or more. Data collection and validation consume the bulk of the time, so a customer that arrives with its own validated position materially shortens the process.