Restricted grants drifted into standalone use within 2 to 4 years in most estates, and the audit reprice consumed the accumulated savings 3 to 5 times over
The discount is real and so is the trap. Nothing in the installed software marks a restricted component, so the restriction exists only in a document nobody operating it has read.
Prepared by Redress Compliance · August 18, 2026 · Oracle licence reviews and audit defences. 30 to 40 reviews run, 2024 to 2025.
Executive summary
Restricted use components drifted into standalone use within 2 to 4 years of purchase in most estates. Every step of the drift was operationally sensible and contractually a breach.
Nobody operating the software could see the restriction. It lives only in the ordering document, and the binaries are identical to the full use ones.
Audit repricing of drifted components ran 3 to 5 times the original restricted use spend. The discount becomes the measure of the exposure rather than a saving.
A restricted to full use upgrade is far cheaper before an audit than during one. It is a negotiation beforehand and a remedy afterwards.
What is a restricted use licence?
A grant of the same software at a reduced price, on the condition that it is used only with or through a defined application, module or scope named in the ordering document. The software is identical and the contract is not.
The pattern is common across the applications portfolio: a database restricted to a single repository, an analytics component restricted to one product's data, or a product restricted to a named integration. The definitions sit in the contract documents governing the order.
Nothing in the installed software marks it
There is no flag, no licence key difference and no warning. The restriction lives in the ordering document, which means the people who could breach it are the people least likely to have seen it.
How does it differ from full use?
In scope rather than capability. Full use allows any lawful purpose. Restricted use allows one named context, and every use outside it is unlicensed regardless of how technically natural that use feels.
| Dimension | Full use | Restricted use |
|---|---|---|
| Permitted scope | Any lawful purpose | Only the named application context |
| Price | Full list with standard discounting | Substantially below full use |
| Visible in the software | No marking needed | No marking at all, contract only |
| Treatment of drift | Not applicable | Repriced as unlicensed full use at list |
| Upgrade path | Not applicable | Negotiable migration to full use |
In practice the grant permits operating the named function and nothing else. Custom schemas, third party reporting feeds and reuse by another application all fall outside it.
The Oracle audit response playbook
What the scripts collect, how to challenge the findings, and the response that limits exposure.
Get the brief →What 30 to 40 Oracle reviews showed
Across roughly 30 to 40 Oracle licence reviews and audit defences run between 2024 and 2025, restricted use grants were among the most common silent failure points in the applications estate. Three patterns recur.
- Restricted use components drifted into standalone use within 2 to 4 years of purchase in most estates.
- Nobody operating the software could see the restriction, because it lived only in the ordering document.
- Audit repricing of drifted components ran 3 to 5 times the original restricted use spend.
A database administrator adds a schema to a convenient database. A reporting team points a tool at the repository. Each step is sensible operationally and a breach contractually.
- Every risky clause flagged with the verbatim quote and page anchor
- Entitlements, caps and protections verified across your whole contract portfolio
- Paste ready replacement language and an evidence trail for the response
What is the audit trap exactly?
Repricing. Where a review finds a restricted component used outside its context, the vendor position is that the use was never licensed at all, and the remedy is full use licensing at list for the whole deployment, often with back support.
That is why the original discount becomes the measure of the exposure. The deeper the restricted use saving, the larger the gap that gets repriced when the drift is found, which is the opposite of how a discount usually behaves.
Drift is invisible until somebody looks for it
No alert fires and no invoice changes. The first signal is usually a review, at which point the accumulated saving has already been spent 3 to 5 times over. The sequence for that conversation sits in the audit practice.
How do you manage the grants in practice?
By writing the restriction down where the operators can see it. Map every restricted grant to its permitted context, record it against the system rather than the contract file, and review it annually.
The annual review is the whole control
Product scope for the family is documented in the product documentation, which is where the named context in an order usually points.
The review is the control. Restrictions do not change but estates do, and the 2 to 4 year drift window is short enough that an annual check catches it while it is still a configuration question rather than a settlement.
Where the context has genuinely outgrown the grant, migrate to full use as a negotiation rather than as a remedy. Clause level language sits in the clause negotiation playbook, and list behaviour in the technology price list guide.
An unlimited agreement is the other route out of a restriction, with its own economics set out in the unlimited agreement guide.
What the reviews measured, 2024 to 2025
Two cuts of the engagement file, one on timing and one on cost.
The window in which most estates moved a restricted component into standalone use without anybody deciding to.
What the audit remedy cost relative to the restricted use purchase that the discount originally funded.
The two figures together are the whole argument for an annual review. The drift window is short and the penalty multiple is large.
Your first five moves
- Pull every ordering document and list which components carry a restriction, because nothing in the installed software will tell you and the operators have never seen the paper.
- Map each restricted grant to its permitted context in writing, naming the application, module or scope the order actually specifies.
- Record the restriction against the system rather than the contract file, so the database administrator and the reporting team see it before they extend anything.
- Review the mapping annually, since grants drifted out of scope within 2 to 4 years and an annual check catches it while it is still configuration.
- Migrate to full use as a negotiation rather than as a remedy. It is cheaper before a review than during one, and the Oracle practice prices the upgrade against the reprice exposure.
Frequently asked questions
What is a restricted use licence?
The same software granted at a reduced price, on the condition that it is used only with or through a defined application, module or scope named in the ordering document.
How does it differ from full use?
In scope, not capability. Full use allows any lawful purpose while restricted use allows one named context, and every use outside that context is unlicensed.
Can you see the restriction in the software?
No. There is no marking, no key difference and no warning. The restriction exists only in the ordering document, which is why the drift is silent.
How fast does usage drift?
Within 2 to 4 years of purchase in most estates reviewed. Each step is operationally sensible, which is exactly why nobody stops to check the paper.
What does the audit remedy cost?
Three to five times the original restricted use spend. The vendor position is that the use was never licensed, so the remedy is full use at list for the whole deployment, often with back support.
What typically causes the breach?
A schema added to a convenient database, or a reporting tool pointed at a restricted repository. Custom schemas, third party feeds and reuse by another application all fall outside the grant.
Is the discount worth taking?
Yes, with the control in place. Without it the discount becomes the measure of the exposure, because the deeper the saving the larger the gap that gets repriced.
How should the grants be recorded?
Against the system rather than the contract file, so the people who could breach the restriction can actually see it. A contract archive is not a control.
How often should it be reviewed?
Annually. Restrictions do not change but estates do, and the drift window is short enough that a yearly check catches it while it is still a configuration question.
When should you upgrade to full use?
Before a review rather than during one. It is a negotiation beforehand and a remedy afterwards, and the price difference between those two positions is the whole point.
