Why Oracle compliance is uniquely complex
Oracle's licensing framework is deliberately complex. Unlike most software vendors, Oracle does not publish a simple, unambiguous set of rules for how its products must be licensed in all deployment scenarios. Instead, licensing rules exist across multiple documents — the Oracle Technology License Agreement, product-specific licence definitions, Oracle's virtualisation policy documents, and the Oracle Partitioning Policy — which interact in ways that create genuine ambiguity even for experienced licensing professionals.
This complexity is not accidental. Ambiguity creates compliance risk, and compliance risk creates leverage for Oracle's LMS (Licence Management Services) team during audits. Oracle's LMS team is trained to identify the most commercially aggressive interpretation of deployment scenarios and present these as compliance shortfalls. Organisations that have not proactively assessed their compliance position before an audit notification arrive are negotiating on Oracle's terms.
The checklist below covers the 35 most common Oracle compliance risk areas, rated by risk level. It is designed to be run by internal teams as a first-pass assessment — not a replacement for a formal licence review with specialist tools, but a structured starting point for identifying where your organisation may have exposure. For the broader context of how compliance fits into Oracle negotiation strategy, see our Oracle license negotiation pillar guide.
How to Use This Checklist
Work through each section with your IT asset management team. Flag any item where you cannot answer "Yes, fully confirmed" as a potential compliance risk requiring investigation. High-risk items flagged should be addressed before your next Oracle renewal or interaction with Oracle LMS. Items marked HIGH risk are those most commonly exploited in Oracle audit findings.
Section 1 — Oracle Database compliance (13 items)
Oracle Database is the highest-value and highest-risk component of most Oracle estates. The combination of complex processor licensing rules, numerous add-on options, and Oracle's aggressive virtualisation policy creates significant compliance exposure for organisations that have not conducted rigorous internal reviews.
Expert Advisory
Want independent help negotiating better terms? We rank the top advisory firms across 14 vendor categories — free matching, no commitment.
Oracle Database — Core Licensing
DB-01
Processor metric confirmed. You have identified whether each Oracle Database deployment is licensed by Named User Plus (NUP) or Processor metric, and have confirmed the appropriate metric per the Oracle licence definition. HIGH
DB-02
Core factor applied correctly. For Processor-licensed deployments, you have applied the correct Oracle Core Factor for each processor architecture (Intel/AMD: 0.5; SPARC T-series: 0.25; others: check Oracle's Core Factor Table). HIGH
DB-03
Named User Plus minimum confirmed. For NUP-licensed databases, you have confirmed compliance with the 25 NUP per Processor minimum (Enterprise Edition) or 5 NUP minimum (Standard Edition 2). MED
DB-04
Development/test environments licensed. All Oracle Database instances in development, test, QA, and staging environments are covered by your licence entitlement or by an active Oracle Technology Network Developer Licence (which restricts use to development only). HIGH
DB-05
Database options inventory complete. You have a full inventory of all Oracle Database options enabled across your estate — including Partitioning, Advanced Compression, Real Application Clusters, Active Data Guard, Advanced Security, and Diagnostics and Tuning packs. HIGH
DB-06
Database options licensed or disabled. Every enabled Database option is either covered by a valid licence entitlement or has been disabled at the database level (disabling requires action in the database itself, not just removing from Oracle's configuration files). HIGH
DB-07
Management packs reviewed. Oracle Enterprise Manager Diagnostic and Tuning packs require separate licensing when used. You have confirmed which EM packs are in use and whether corresponding licence entitlements exist. HIGH
DB-08
Edition compliance confirmed. Each Oracle Database instance is running on the edition for which you hold a licence (Enterprise Edition, Standard Edition 2). Instances cannot use EE features when only SE2 is licensed. MED
DB-09
Data Guard architecture reviewed. Data Guard standby instances require Active Data Guard licensing only if the standby is "open" and actively serving read queries. Cold standbys and warm standbys not serving reads are covered by the primary licence. MED
DB-10
RAC licensing confirmed. Real Application Clusters (RAC) requires licensing all nodes in the cluster. You have confirmed that all RAC nodes are within your licence entitlement and that the One Node licence (if applicable) is not being exceeded. HIGH
DB-11
Autonomous Database licences reviewed. Oracle Autonomous Database on OCI is typically licensed separately from on-premise Database entitlements. BYOL (Bring Your Own Licence) entitlements used on OCI are confirmed to not also be claimed for on-premise deployments simultaneously. MED
DB-12
Third-party applications using Oracle confirmed. All third-party applications accessing Oracle Database are identified, and any that provide access to an unspecified number of users are licensed using the Processor metric (not NUP). MED
DB-13
Support entitlement matched to deployment. Annual support entitlement matches your active licence deployment. Products where support is paid but the licence has been fully retired should be flagged for support termination to reduce costs. LOW
Section 2 — Oracle Java SE compliance (6 items)
Oracle's January 2023 Java SE licensing change created the largest involuntary compliance event in enterprise software history. The shift to per-employee pricing means that organisations are now potentially non-compliant if they have any Oracle JDK deployments without a current Java SE subscription covering their entire employee base. For a detailed analysis of Java SE options, see our Oracle Java licensing 2026 guide.
Oracle Java SE Compliance
JV-01
Oracle JDK inventory complete. You have a complete inventory of all Oracle JDK deployments across servers, workstations, and developer machines — including versions earlier than JDK 8u211 (which are under the old BCL licence) and versions from JDK 8u211 onwards. HIGH
JV-02
Per-employee subscription coverage assessed. If you are running Oracle JDK 8u211 or later, you have assessed whether your organisation requires a Java SE subscription covering all employees. The 2023 model charges per employee regardless of how many actually use Java. HIGH
JV-03
OpenJDK migration plan assessed. You have assessed which Java workloads could migrate to certified OpenJDK distributions (Eclipse Temurin, Amazon Corretto, Microsoft Build of OpenJDK) to eliminate Oracle Java SE subscription exposure. MED
JV-04
Oracle Java SE subscription entitlement confirmed. If you hold an Oracle Java SE subscription, the employee count in the subscription matches your current global employee headcount. Subscription agreements typically require annual true-up for employee count changes. HIGH
JV-05
Application server Java runtimes identified. Java runtimes bundled within application servers (WebLogic, JBoss, Tomcat) have been identified and their Oracle JDK dependency assessed. Some application server licences include Java rights; others do not. MED
JV-06
Java version consistency managed. You have a process for preventing unauthorised Oracle JDK updates across the estate, ensuring developers and automated processes do not introduce Oracle JDK deployments without IT asset management oversight. LOW
Section 3 — Oracle Middleware compliance (6 items)
Oracle Middleware — principally WebLogic Server, SOA Suite, Oracle Service Bus, and Oracle Fusion Middleware — carries its own complex licensing rules, including processor licensing, virtualisation policy application, and the interaction between application server licences and Java rights. For detailed guidance, see our Oracle Middleware licensing guide.
Free Resource
Get the IT Negotiation Playbook — free
Used by 4,200+ IT directors and procurement leads. Oracle, Microsoft, SAP, Cloud — all covered.
Oracle Middleware Compliance
MW-01
WebLogic Server inventory complete. All WebLogic Server instances across production, development, and test environments are inventoried. WebLogic requires licence coverage for development environments except where covered by an Oracle Technology Network Developer Licence. HIGH
MW-02
WebLogic edition confirmed. You have confirmed that each WebLogic instance is running the edition for which you hold a licence (WebLogic Server Standard Edition or Enterprise Edition). Enterprise-only features (clustering, RAC integration) are only permitted under Enterprise Edition licences. MED
MW-03
Oracle SOA Suite options reviewed. If Oracle SOA Suite is deployed, you have confirmed that the specific components in use (SOA Foundation, B2B, BPM Suite, OSB) match your licence entitlement. Individual SOA Suite components are separately licensed. MED
MW-04
Identity and Access Management reviewed. Oracle Identity Manager, Oracle Access Manager, and Oracle Identity Governance deployments are inventoried and licence coverage confirmed. IAM products are frequently deployed without corresponding licence entitlements in acquired entities. MED
MW-05
Forms and Reports assessed. Oracle Forms and Reports deployments — often inherited from legacy applications — are confirmed to be within licence entitlement. Legacy Forms deployments are a common source of compliance gaps in organisations that have undergone M&A. LOW
MW-06
Middleware support costs reviewed. Annual support costs for Middleware products are matched against active usage. Middleware products that have been decommissioned but remain on Oracle's support schedule should be terminated to reduce unnecessary support expenditure. LOW
Section 4 — Virtualisation and cloud compliance (6 items)
Virtualisation is the most contentious area of Oracle compliance. Oracle's partitioning policy holds that only "hard partitioning" technologies (Oracle VM, Solaris Zones, LDOM) allow licensing of only the partitioned VMs. All other virtualisation platforms — including VMware, Hyper-V, KVM, and most container technologies — require all physical processors in the cluster to be licensed. This policy is not universally agreed to be legally enforceable, but Oracle applies it aggressively in audits.
Virtualisation and Cloud Compliance
VM-01
VMware cluster topology assessed. For Oracle Database or Middleware deployed in VMware environments, you have identified all physical hosts in VMware clusters where Oracle VMs can run. Oracle's policy requires all processors on all hosts in the cluster to be licensed. HIGH
VM-02
VMware DRS and vMotion governance in place. If Oracle workloads are running in VMware, governance controls are in place to prevent Oracle VMs from migrating across hosts in unlicensed clusters via DRS or vMotion. Oracle does not accept vMotion restrictions as a licensing mitigation. HIGH
VM-03
Container deployments assessed. Oracle Database deployments in Docker, Kubernetes, or other container platforms have been assessed for licensing implications. Oracle's official position is that containers on non-hard-partitioned hosts require full physical host licensing. HIGH
VM-04
OCI BYOL licences validated. Oracle Database licences used under BYOL on OCI are confirmed as not simultaneously used for on-premise deployments. BYOL licence portability between on-premise and cloud requires that the on-premise deployment is retired when the cloud BYOL is active. MED
VM-05
AWS/Azure Oracle deployments reviewed. Oracle Database deployments on AWS (EC2, RDS with BYOL) and Azure (VM with BYOL) have been assessed. Oracle's licensing policy on AWS and Azure differs — AWS Dedicated Hosts and Azure Dedicated Host allow processor-based licensing; shared infrastructure does not. MED
VM-06
Disaster recovery environments licensed. Oracle Database disaster recovery instances (whether on-premise or cloud) are within licence entitlement or covered by the Oracle failover licence terms (which permit a 10-day annual failover period under specific conditions). MED
Section 5 — Governance and process compliance (4 items)
Process failures — rather than technical complexity — are the underlying cause of many Oracle compliance gaps. Organisations without robust software asset management processes for Oracle frequently accumulate licence gaps through organic IT change, M&A activity, and shadow IT deployments that bypass the formal procurement process.
Governance and SAM Process
GV-01
Oracle licence register maintained. A current Oracle licence register exists, mapping each licence entitlement (product, edition, metric, quantity) to its corresponding deployment. The register is updated when new licences are purchased or deployments change. HIGH
GV-02
M&A licence review process exists. Your organisation has a documented process for assessing Oracle licence implications when acquiring or merging with another entity. Acquired entities frequently bring Oracle compliance gaps that become the acquiring organisation's liability. MED
GV-03
Oracle procurement controls in place. All Oracle software procurement (including cloud subscriptions) goes through a single controlled channel with oversight from IT asset management. Shadow IT Oracle deployments are the leading cause of undetected compliance gaps. MED
GV-04
LMS audit response plan exists. Your organisation has a documented response plan for Oracle LMS audit notifications, including who is responsible for engaging with Oracle, which external advisors to engage, and what the initial response protocol is. LOW
Next steps after completing the checklist
If your self-assessment has identified flagged items — particularly in the HIGH-risk categories — the appropriate next steps depend on the severity and number of gaps identified.
For organisations with isolated, well-understood gaps (for example, a single Database option that is enabled but not licensed), the immediate action is to either license the gap or disable the feature. Disabling Oracle Database options requires action at the database level using Oracle's appropriate procedures — it is not sufficient to simply stop using the feature from an application perspective, as Oracle's LMS tools will detect that the option has been enabled historically.
For organisations with systemic gaps — particularly in virtualisation environments, Java SE, or across multiple Database options — a formal independent licence position review with specialist tools is strongly recommended before Oracle initiates any audit. Organisations that self-disclose compliance gaps to Oracle from a position of incomplete information frequently create worse commercial outcomes than those that first establish a complete, defensible independent position.
A specialist Oracle licensing advisor can conduct a comprehensive licence position review, produce a defensible independent measurement, and advise on remediation strategies that minimise cost while achieving compliance. For guidance on selecting the right advisor, see our Oracle negotiation firm rankings and our software audit defense buyer's guide.
Compliance gaps identified? Get an independent Oracle licence review before Oracle does.
Expert-led assessment — confidential and independent of Oracle
Get Expert Help →
The Oracle cluster also includes guidance on what to do when Oracle initiates an audit — read the Oracle audit defense playbook for step-by-step instructions on managing the LMS process. For organisations looking to reduce Oracle costs proactively, see our guide on reducing Oracle support costs and the Oracle licence optimisation guide. If you are approaching an ELA renewal, the Oracle ELA renewal guide covers how compliance position affects negotiation leverage.
For the broader Oracle negotiation strategy context, see our Oracle license negotiation pillar guide, which covers ELA, ULA, Java, OCI, audit defense, and support cost reduction in a single comprehensive framework. You can also download our free Oracle licensing white paper for a 50-page reference guide to Oracle's full licensing framework.
Frequently asked questions
How often should organisations run an Oracle license compliance review?
Organisations with significant Oracle deployments should run a formal internal compliance review at minimum annually — ideally 12 months before any Oracle contract renewal, ELA certification, or ULA expiry. Organisations that have recently undergone M&A activity, cloud migration, or virtualisation infrastructure changes should run an immediate compliance review, as these events frequently create unintended licence gaps.
What are the highest-risk Oracle compliance areas?
The three highest-risk Oracle compliance areas are: Oracle Database in VMware environments (where Oracle's policy of requiring all physical hosts to be licensed is widely misunderstood), Java SE licensing under the post-2023 per-employee model (where many organisations have not assessed their actual employee count exposure), and Oracle Database options and management packs (where features are frequently enabled automatically without being licensed). These three areas account for the majority of material Oracle audit findings.
What happens if Oracle finds a compliance gap during an audit?
Oracle's LMS team will produce a compliance finding document quantifying the shortfall in licences against their assessment of deployment. Oracle will then present options — typically a new licence purchase (often bundled with an ELA) or a settlement payment. Initial Oracle audit claims are frequently overstated by 30–70%. Organisations with specialist audit defense support typically settle at significantly lower amounts than those that engage with Oracle's LMS team directly without preparation.
Can Oracle audit us if we have an active support contract?
Yes. Oracle's right to audit is typically contained within the licence agreement itself, not the support contract. Maintaining an active support contract does not limit Oracle's right to conduct a licence audit. However, the support relationship does affect Oracle's commercial motivations — Oracle is less likely to initiate aggressive audit action against customers in active renewal negotiations or with significant cloud migration plans, as this damages the commercial relationship.