Internal Oracle license audits, run every year. Find the gap before Oracle does.

An internal Oracle license audit repeats the measurement Oracle's auditors would take, on your schedule, with the result kept inside the company. Its purpose is to know your own license position before anyone at Oracle proposes one.

The internal audit produces a working file for your own team. It is never written to be sent to Oracle, and that single fact shapes how it is scoped, staffed and worded.

Most compliance programs fail at the same point. They produce an inventory of installs, call it an audit, and never reconcile it against what the company actually bought. A real internal audit has three outputs: a measured position, a dated evidence pack, and a short list of decisions for a senior sponsor.

What have we seen in Oracle self audits in 2024 and 2025?

Companies that measure themselves every year handle Oracle's audit letter differently from those that do not. Fredrik Filipsson ran roughly 35 to 45 Oracle license reviews between 2024 and 2025, and three patterns came up repeatedly.

• Options and packs in use by accident. Roughly 7 of 10 environments we measured had database option or management pack usage that no one had planned. Diagnostics, Tuning and Partitioning were the usual suspects.
• Smaller settlements. Companies with their own measurement settled formal audits at a small fraction of the opening claim, because they could contest line items on day one instead of in month four.
• Lost months. Companies without an entitlement repository spent 3 to 6 months rebuilding proof of purchase that a prepared company produced in days.

In each pattern, what separated the two groups was whether a measurement existed before the audit notice did.

What should an internal Oracle license audit cover?

It should cover every environment where Oracle software runs or could run, including the layers that no one thinks of as production. A partial scope produces false comfort, which is worse than knowing you have a gap.

The layers, and the evidence each one has to produce

The omissions that cost the most

• Embedded runtimes. A third party application that ships its own Oracle runtime is still your exposure unless its vendor holds the license. Our note on Java in third party appliances covers how to tell.
• Developer machines. Individual installs are small in count and large in argument, particularly for Java.
• Container images. A base image carrying an Oracle runtime replicates faster than any approval process can follow.
• Retired but running. Systems decommissioned on paper and still powered on in a rack.
• Acquired entities. Businesses that joined the group and never made it into the repository.

Build the entitlement repository once, and build it properly

The repository is the half of the exercise most programs skip, and it is the half that costs months when an audit lands. Deployment data can be regenerated in a week. Twenty years of contract history cannot.

• Every ordering document. Program, metric, quantity, date, and the legal entity that bought it.
• Every master agreement. Include the older ones. They frequently carry better terms than the current generation of Oracle paper.
• Every amendment. Negotiated protections are the first thing lost in a reorganization or an acquisition.
• Support records. Customer support identifiers mapped to the licenses they cover, with the renewal history.
• Certification and closure letters. Any document stating that a prior review or an unlimited agreement was closed, including your ULA certification if you had one.
• Assignment consents. Written approvals covering entities that joined or left the group.

Index it by program rather than by contract folder. The question you will be asked is always what license covers this instance, and a repository organized by contract cannot answer that quickly.

How often should you run an internal Oracle license audit?

Run a full measured pass once a year, a quarterly delta on what changed, and an extra pass whenever one of six events happens. The calendar matters as much as the method.

Tie the annual pass to your largest renewal

Start the full pass roughly twelve months before your largest Oracle renewal. That leaves time to fix configuration, correct the entitlement record, and hold a settled position before the commercial conversation begins.

Your own financial year end has no connection to Oracle's commercial calendar. A renewal is when Oracle's account team has a number to hit, and when your own figure is worth the most.

The six events that justify an extra pass

1. An acquisition or divestiture completes. Entitlement mapping is never easier than in the first quarter after close. Our guide to the assignment clause in a merger or divestiture explains why.
2. A hardware refresh. New processors change the core calculation before any workload changes.
3. A migration to or from public cloud. The counting method changes with the platform.
4. A virtualization platform change. Cluster boundaries and management domains get redrawn, usually without a licensing review.
5. An unlimited agreement nears its end. Certification counts need months of preparation, not weeks.
6. A support reduction is under consideration. Measure before you request anything, because the request itself starts a conversation with Oracle.

Who should run an internal Oracle audit?

Someone who does not own the systems being measured. That single rule prevents most of the quality problems we see in self audits.

Four roles, and why they must stay separate

Why the database team should not own the conclusion

Database administrators produce the most accurate data in the building and the least useful conclusions. A technically true statement about a feature is not a licensing position.

Keep the DBAs on measurement and explanation. The step from usage data to an entitlement conclusion belongs to whoever holds the contracts, because only they can say which ordering document covers which server.

When to run the whole exercise under counsel

• A vendor approach is live or expected. How findings are written matters more once a review is foreseeable.
• You suspect material exposure. A large unresolved gap is a legal question as well as a commercial one.
• The environment crosses jurisdictions. Data handling rules differ between countries, and so does privilege.
• A transaction is in progress. Due diligence findings travel further than anyone expects.

How do you measure Oracle usage the way Oracle's auditors would?

Use the same collection method the auditor would use, then control the output as the sensitive material it is. Measuring with anything else leaves a gap between your numbers and theirs, and that gap becomes the negotiation.

The scripts distributed through Oracle license management services report every option ever enabled and the high water marks an auditor would price. That is exactly why you want to see their output first. Oracle's audit team, now called Global Licensing and Advisory Services, packages the same collection as the Oracle Collection Tool.

What the measurement catches that a spreadsheet cannot

• Historical option usage. Features enabled once, years ago, and never used since still appear in the record.
• Feature high water marks. Peak events that set a licensable count long after the event itself.
• Real core topology. Actual sockets and cores, converted with the processor core factor table. Intel Xeon cores carry a factor of 0.5.
• Edition drift. Standard Edition installed on hardware that has outgrown its socket limits. Standard Edition 2 may only be licensed on servers with a maximum of 2 sockets.
• Virtualization reach. Where a workload could run, which is the number Oracle's partitioning policy is written around.

How to check your own position before running the full collection

Several checks need nothing more than DBA access and an afternoon. They tell you where the collection will find something, so you can plan the reconciliation.

• DBA_FEATURE_USAGE_STATISTICS. The view that records which features were detected, with first and last usage dates. Our note on first and last sample dates explains how to read them.
• Oracle's options and packs usage script. Published in My Oracle Support Doc ID 1317265.1. It reads the same views but filters detections Oracle itself treats as benign, so run it before the collection tool.
• CONTROL_MANAGEMENT_PACK_ACCESS. On Enterprise Edition this parameter defaults to DIAGNOSTIC+TUNING, which is how most unplanned pack usage starts.
• vCenter or hypervisor inventory. Export cluster membership, host models and core counts, and keep the export dated.
• Oracle Global Deployment Matrix. Oracle's own form for listing deployed programs, useful as a checklist of what the auditors will ask about.

Commercial SAM tools can help with discovery. Oracle's audit team lists verified tools from vendors including Flexera, ServiceNow and Snow Software for Oracle Database and its options. A verified tool produces data Oracle will accept, but it still cannot tell you which ordering document covers which server.

Controlling the output once it exists

1. Store it in one controlled location. Keep it out of mailboxes, off laptops and away from shared drives the whole team can browse.
2. Name the access list. Owner, sponsor, counsel, and the named measurement staff. No one else by default.
3. Date and version everything. An undated measurement is worth very little when you need to prove when something changed.
4. Set a retention period. Long enough to show a trend, chosen deliberately rather than by accident, and agreed with counsel.
5. Read the output properly. The guide to interpreting script output covers what each result does and does not prove.

How do you put a price on an internal audit finding?

Multiply the gap in processor licenses by Oracle's list price for the missing product, then add annual support at 22 percent of the license fee. List price is the right planning figure because it is where any audit claim starts.

Worked example: pack usage on more hosts than you licensed

Say the collection records Diagnostics Pack and Tuning Pack usage on 14 database hosts, and your ordering documents cover 6. Each host runs 16 Intel Xeon cores. Tuning Pack also requires a Diagnostics Pack license, so both products apply on every uncovered host.

Treat that $800,000 as a planning figure. If the usage came from the parameter default and a handful of Enterprise Manager page views, the fix is to set the parameter to NONE on the 8 hosts and record the date. The historical detections remain and still need an explanation.

Worked example: one database on a large VMware cluster

Now say Oracle Database Enterprise Edition runs on 2 hosts inside a 10 host vSphere cluster, each host with 32 Xeon cores. Oracle treats VMware as soft partitioning, so its auditors will count every host the database could move to.

• Oracle's count. 10 hosts x 32 cores x 0.5 = 160 licenses. At $47,500 each, $7,600,000 at list.
• A contained count. 2 hosts x 32 cores x 0.5 = 32 licenses, or $1,520,000.
• The difference. $6,080,000, decided by where the cluster boundary sits and whether you can document it. See our design note on dedicated VMware clusters for Oracle.

How does the internal report differ from anything you send Oracle?

Completely, and on purpose. The internal file is an exploratory working document full of open questions. A production pack is a narrow, factual answer to a question Oracle actually asked.

Confusing the two is the most damaging mistake in self auditing. It is also the easiest to avoid, because the difference is a matter of structure rather than judgment.

Write findings, not confessions

The internal report should record what was measured, what remains open, and what decision is needed. It should not record conclusions about legal compliance that no one in the room is qualified to reach.

• Write this. "Diagnostics pack usage recorded on 14 hosts. Entitlement covers 6. Open item: confirm whether usage predates the 2021 amendment."
• Avoid this. "We are unlicensed on 8 hosts and exposed to a claim."
• Attribute the method. State what was measured, with which tool, on which date.
• Separate fact from estimate. A priced exposure is a planning figure, not an admission, and it should be labeled as one.
• Keep the tone even. Alarmed language in an internal document does real damage later and adds nothing now.

None of this is about hiding anything. It is the ordinary discipline of writing an accurate document instead of an anxious one, and counsel should review the wording wherever the numbers are material.

How do you fix findings before they become audit claims?

Rank findings by priced exposure, then close them in that order. Most option and pack findings are configuration changes rather than purchases, provided you catch them early.

What remediation can and cannot do

Disabling a feature stops the exposure from growing. It does not delete the historical record, because usage history is cumulative and the measurement will still show that the feature was used.

Be straight with yourself about this. If material unlicensed use occurred, it is a real liability to quantify and address. Trying to tidy the record away, for example by purging the usage views, turns a commercial problem into a conduct problem.

When a finding should become a purchase

Buy when the capability delivers value you would have paid for anyway. Negotiate it as planned spend inside a normal deal cycle, where discounts apply, rather than as a compliance settlement.

The same product costs materially less when the conversation is about a roadmap than when it is about a shortfall. That timing difference is the strongest argument for measuring early.

Why we reject the advice to avoid running Oracle's scripts yourself

A common recommendation is to keep Oracle's scripts away from your own systems, because the output creates a discoverable record of your position. We disagree. Across the reviews we ran, companies that refused to measure themselves carried larger unknown exposure and settled formal audits at several times the rate of those that measured.

The output is not the risk. The unmanaged usage it reveals is the risk, and that usage exists whether or not anyone looks. The better course is to measure, write the document carefully, fix what can be fixed, and put an accurate figure on what cannot.

Know your own number before Oracle proposes one. Everything else in audit defense is a variation on that single instruction.

Which mistakes undermine an internal Oracle audit?

The expensive mistakes are about scope and paperwork more than technology. Each of these has turned a manageable finding into a long negotiation.

• Treating an install list as the audit. Without a reconciliation to ordering documents, you know what runs but not what is covered.
• Leaving out non production. Oracle licenses development and test servers the same way as production unless your contract says otherwise.
• Trusting a SAM tool for entitlement. Discovery tools see deployments. They cannot read the amendment that changed your metric.
• Handing the internal file to anyone outside the access list. Resellers and implementation partners work closely with Oracle, and sharing with them can weaken any privilege claim over the document.
• Starting after the audit letter arrives. Oracle's standard audit clause gives 45 days written notice. That is enough time to collect data but too short to rebuild twenty years of contract history.

How does an internal audit change a formal Oracle audit?

It shifts the argument from discovery to reconciliation. A formal audit starts from Oracle's data and Oracle's assumptions, and a company with its own measured baseline can test both from the first meeting.

What a prepared company does differently

1. Answers the notice through one owner, with counsel reading the correspondence.
2. Agrees scope against a repository that already exists, instead of building one under time pressure.
3. Reconciles every finding against its own dated output, line by line.
4. Negotiates from its own figure, using the Oracle audit negotiation guide, instead of reacting to the opening claim.

Prepared companies negotiate. Unprepared companies pay, and mostly they pay for the time it takes them to find out what they own. See what an Oracle audit actually involves for the process this feeds into, and our Oracle audit response guide for the full response plan.

What Oracle's auditors will say, and how to answer

• "Just run the scripts on everything and we will sort it out." Agree the scope in writing first: programs, legal entities and servers. Produce output for that scope only.
• "Diagnostics Pack shows as used across your databases." Show your own dated output, the first and last usage dates per host, and the date the parameter was set to NONE.
• "Every host in the vCenter needs a license." Show the documented cluster boundary. Oracle's partitioning document says it is for educational purposes and may not be incorporated into any contract, so ask which contract term supports the count.
• "A cloud or unlimited agreement would make this finding go away." Settle the compliance figure on its own terms first. Then judge the purchase as planned spend.
• "Please share your internal review so we can move faster." Decline. The standard clause requires you to run Oracle's measurement tools and provide the resulting data for the audited programs. Your own analysis of that data is a separate document, and it stays inside the company.

Contract terms worth asking for at your next renewal

• A written scope step. Scope agreed before any collection, so the audit cannot widen as it goes.
• A limit of one audit every 12 months. Oracle's standard program audit clause sets 45 days notice but no frequency limit. Its cloud services schedule already caps audits at once every 12 months, so ask for the same on licensed programs.
• A draft report stage. Time to respond to draft findings before the 30 day remedy period in the standard clause starts to run.
• Use of audit data. The standard clause already puts audit data under the agreement's nondisclosure terms. Add that the data is used only for the audit, and that any third party auditor signs a confidentiality agreement with you.
• Preserved definitions. Older metric definitions and negotiated protections carried forward explicitly, so they survive the new order.

The number you carry into the room

The output of the annual pass is one figure with a range around it, plus the evidence that supports both. That figure is the reason to self audit at all.

Without it, Oracle's number is the only number in the conversation. With it, the discussion becomes a line by line reconciliation of two positions, and each gap has to be argued on the evidence.

What to do next

1. Build the repository first. Ordering documents, amendments and support identifiers, indexed by program.
2. Fix the date. Set the annual pass for twelve months before your largest renewal.
3. Separate the four roles. Put the conclusion with whoever holds the contracts.
4. Collect across everything. Include non production, standby and developer machines.
5. Price every finding. Use the core factor table and list price so each one carries a number from day one.
6. Write findings and open items. Never legal conclusions.
7. Remediate and record. Fix what is configuration, put a truthful figure on what is not, and date every change.
8. Keep the cycle running. Schedule the next full pass at twelve months, run quarterly deltas, and add the six event triggers to your change process.

Frequently asked questions