Work through all 20 items in sequence. Mark each as compliant (✓), non-compliant (✗), or unknown (?). High-risk items represent the most common triggers for Oracle audit findings. Download our Oracle Audit Defence Kit if you identify gaps.
Section 1
Processor Identification and Core Factor Lookup
01
You have identified every physical server in your estate running Oracle software and recorded the exact processor model installed on each host.
High
Expert note: Without knowing the precise processor model — Intel Xeon, AMD EPYC, SPARC, IBM POWER — you cannot look up the correct core factor from Oracle's published table. A processor recorded generically as 'Intel Xeon' may carry a core factor of 0.25 or 0.5 depending on the specific model generation. Oracle's LMS team will identify the exact CPU model during a script-based audit and apply the most conservative factor if your records are vague. Confirm processor models from hypervisor inventory tools, BMC records, or direct hardware inspection.
02
You are using Oracle's current Processor Core Factor Table (updated January 2026) — not an earlier version — to calculate licence requirements.
High
Expert note: Oracle updated the Core Factor Table in January 2026 to add new Intel Xeon 6 series processors and expand AMD EPYC 4th/5th generation entries. If your licence calculations are based on a 2023 or 2024 version of the table you may be using incorrect factors — either over-reporting licences (wasting money) or under-reporting (creating compliance risk). Download the current table from oracle.com/contracts/docs/processor-core-factor-table-070634.pdf and revalidate your calculations.
03
For each server, your licence calculation multiplies the number of physical cores by the correct core factor for that specific processor model — not by hyper-thread or logical CPU count.
High
Expert note: Oracle licences are based exclusively on physical cores, not logical CPUs or hyper-threads. However, many IT asset management tools default to reporting logical CPU counts. A 32-core Intel Xeon server with hyper-threading enabled will show 64 logical CPUs — but Oracle requires only 32 × 0.5 = 16 processor licences. Using logical CPU counts overstates your licence obligation by 100%. Validate that your ITAM tool is reporting physical core counts, not logical counts.
04
You have confirmed whether AMD EPYC processors in your estate are 3rd, 4th, or 5th generation, as all three generations carry a 0.5 core factor per Oracle's 2025 update.
Medium
Expert note: Oracle's May 2025 update confirmed that AMD EPYC 3rd, 4th, and 5th generation processors all carry a core factor of 0.5. For organisations deploying Oracle on AMD-based infrastructure, this is highly favourable: a 96-core AMD EPYC server requires only 48 processor licences. However, the generation must be correctly identified — earlier AMD Opteron processors carry different factors. Confirm exact AMD processor model strings against the current Core Factor Table entry.
05
Intel Xeon processors in your estate have been individually looked up in the Core Factor Table — including the latest Xeon 6 series added in January 2026 — rather than assumed to be 0.5.
Medium
Expert note: Most modern Intel Xeon processors carry a 0.5 core factor, but this is not universal. Older Intel Xeon 5xxx and 7xxx series may carry factors of 0.25, and some specialist processors have different designations. The January 2026 Core Factor Table update added new Xeon 69xxP, 67xxE, and other 6-series processors all at 0.5, but these must be confirmed individually. Never assume a core factor without checking the published table for the specific processor model and stepping.
Unsure which core factor applies to your hardware?
30-minute confidential assessment. Buyer-side only.
Section 2
Virtualisation and Hardware Partitioning
06
Oracle Database or Fusion Middleware deployed on VMware ESXi has been licensed either for the entire physical server's cores or per the specific virtual machines with Oracle Hard Partitioning compliant technology — not on virtual CPU counts alone.
High
Expert note: VMware is not recognised by Oracle as hard partitioning. Oracle's standard position is that all physical cores on a VMware host running any Oracle workload must be licensed — even if only one small VM runs Oracle. This is one of the most common and expensive compliance gaps in enterprise Oracle estates. The only accepted hard partitioning technologies are Oracle VM (OVM), Solaris Containers/Zones, IBM LPAR, and HP vPar. If you run Oracle on VMware, licence the physical host in full.
07
Oracle workloads running on VMware have been specifically assessed against Oracle's partitioning policy, and you have documented whether you are licensing the entire physical cluster or individual hosts within the cluster.
High
Expert note: In a VMware cluster where Oracle VMs can vMotion between hosts, Oracle's position is that all physical hosts in the cluster must be licensed — not just the hosts where the Oracle VM currently resides. This cluster-licensing interpretation is disputed by some organisations, but Oracle consistently applies it during audits. If you have Oracle on a large VMware cluster, the licence exposure can be enormous. Document your cluster topology and seek specialist advice before your next audit.
08
Oracle Database Exadata deployments correctly apply the core factor for the specific Intel Xeon processor installed in the Exadata compute nodes rather than using a blanket estimate.
Medium
Expert note: Exadata systems use Intel Xeon processors whose core factor must be confirmed from the Core Factor Table for the specific Exadata hardware generation. Newer Exadata X10M systems use current-generation Xeon processors at 0.5 factors, but older X6M and X7M systems use different processor models. Exadata licensing is further complicated by the Exadata Full Rack/Half Rack/Quarter Rack distinctions. Confirm the specific Xeon model from your Exadata configuration sheet and validate against the current Core Factor Table.
09
SPARC-based Oracle servers in your estate use the correct core factor for the specific SPARC processor model — not a generic SPARC factor.
Medium
Expert note: Oracle's Core Factor Table includes entries for SPARC T-series, M-series, and SPARC64 processors, each with distinct core factors. SPARC T8 processors carry a factor of 0.25 (the most favourable), while older SPARC64 VII+ processors carry 0.5. If you have a mixed SPARC estate or are migrating from older to newer SPARC hardware, validate each system's processor model individually. Some legacy SPARC Oracle Solaris deployments use processor models that no longer appear in current Core Factor Tables — seek specialist clarification.
10
IBM POWER servers running Oracle software have been licensed using the appropriate core factor from Oracle's table — which differs by POWER generation.
High
Expert note: IBM POWER processors have historically carried core factors of 1.0 for most POWER 5/6 generation systems, and 0.75 for POWER 7 and later. Oracle's Core Factor Table reflects specific POWER chip versions. IBM AIX and IBM i deployments running Oracle must use IBM LPAR as the partitioning technology (which Oracle recognises) to avoid licensing entire physical systems. If you run Oracle on IBM POWER, confirm both the POWER chip version and the LPAR configuration before calculating licence requirements.
Section 3
Cloud and Hybrid Deployments
11
Cloud deployments on authorised cloud environments (AWS, Azure, GCP) correctly apply the published vCPU-to-licence conversion ratios rather than the on-premises Core Factor Table.
High
Expert note: Oracle's Processor Core Factor Table explicitly does not apply in Oracle's Authorised Cloud Environments. On AWS EC2 and Azure IaaS, Oracle licences BYOL database workloads at a ratio of 1 processor licence per 2 vCPUs (Intel/AMD) or 1 processor licence per 1 vCPU (other chips), using the Authorised Cloud Environment document rather than the Core Factor Table. Applying on-premises core factors to cloud deployments produces incorrect calculations. Review the current Oracle Processor Core Factor Table and the Authorised Cloud Environments document in tandem for any hybrid estate.
12
You have a documented policy that prevents new Oracle software from being provisioned on hardware before a licence calculation is completed and signed off.
Medium
Expert note: The most common cause of licence exposure is organic deployment growth where Oracle workloads migrate to new hardware without a corresponding licence review. Establish a change management gate that requires a core factor calculation — signed off by someone with Oracle licensing expertise — before any new Oracle deployment is approved. This is especially critical in virtualised environments where VM migration can inadvertently move Oracle workloads to larger or differently-configured hosts.
13
Oracle processors assigned to development, test, or non-production environments have been reviewed — since Oracle requires these to be licensed unless a specific test/development licence applies.
High
Expert note: Oracle requires that all deployments of Oracle software — including development, test, and staging environments — be licensed, unless a specific Development and Test Environment licence or Named User Plus licence applies. The core factor calculation applies equally to non-production environments. Many organisations discover significant unlicensed exposure in their dev/test environments only during an Oracle audit, by which point Oracle asserts that full production processor licence rates apply.
14
Your processor count documentation has been prepared in a format consistent with Oracle's LMS Collection Tool output — to avoid discrepancies if Oracle requests a script-based audit.
Medium
Expert note: Oracle's LMS Collection Tool (OLCT) generates processor and core count reports in a specific format. If your internal documentation uses different terminology or categorisation, there can be apparent discrepancies when compared with Oracle's script output — even if the underlying licences are the same. Prepare a cross-reference document that maps your internal hardware inventory to Oracle's OLCT output format before any audit conversation begins.
Section 4
Governance, Tooling, and Audit Readiness
15
You have verified that Oracle Database or other products licenced by Named User Plus (NUP) meet the minimum processor licence equivalent (currently 25 NUP per processor for most products) where applicable.
Medium
Expert note: Oracle's NUP licensing requires a minimum of 25 Named User Plus licences per processor for most Oracle Database and some middleware products. Organisations sometimes switch from Processor to NUP licensing to save costs but fail to apply the minimum rule, creating a compliance gap. If you are on NUP licensing, multiply your processor count (using core factors) by 25 and verify you have at least that many NUP licences for each applicable product.
16
Your IT asset management platform is configured to flag hardware changes — CPU upgrades, new server additions, VM host migrations — that would trigger a licence recalculation under the Core Factor Table.
Medium
Expert note: Infrastructure teams frequently upgrade CPUs, add hosts to clusters, or commission new servers without involving the Oracle licensing team. An automated trigger in your ITAM platform that fires when hardware changes affect Oracle-related hosts gives you early warning before an exposure materialises. Configure alerts based on host attributes — processor model, physical core count, Oracle workload presence — so that licencing reviews happen proactively.
17
You have engaged an independent Oracle licensing specialist to validate your Core Factor Table calculations within the past 24 months, particularly if your hardware estate has changed significantly.
High
Expert note: Oracle's LMS team uses specialist software to analyse your infrastructure and compute licence requirements. The calculation complexity — multiple processor types, virtualisation layers, cloud deployments, and product-specific rules — means that self-assessed calculations frequently contain errors. Independent validation by someone with direct LMS experience ensures that your calculations are defensible, that any errors are corrected before Oracle identifies them, and that you are not paying for more licences than you need. Redress has validated processor counts across hundreds of Oracle estates and regularly identifies both over- and under-licensing.
18
For Oracle Java SE deployments, you have confirmed that the correct licence metric applies — Employee count, Named User Plus, or Processor — and that core factors are being applied correctly where Processor metric is in use.
High
Expert note: Oracle Java SE licensing changed significantly in 2023 to an employee-based model. However, for organisations on legacy Java SE Processor licences, the Core Factor Table still applies. If your Java estate is on the post-2023 employee model, core factors do not apply; but if you have any residual Processor-metric Java SE licences from legacy agreements, the Core Factor Table calculation must be maintained. Confirm the precise licence metric for every Java SE entitlement in your estate.
19
You have mapped every Oracle product in your estate to its applicable licence metric — Processor, Named User Plus, Employee, or Application Specific Full Use — before applying the Core Factor Table.
Medium
Expert note: The Core Factor Table applies only to products licenced by the Processor metric. Named User Plus, Employee-based, and Application Specific licences use different counting rules where physical cores and core factors are irrelevant. Many enterprises apply core factor calculations across all Oracle products, unnecessarily complicating their licence position. Map each product to its metric first, then apply the Core Factor Table only to Processor-metric products.
20
Your Core Factor Table calculations and supporting hardware documentation are stored securely, version-controlled, and accessible to your Oracle audit response team without relying on a single individual.
Medium
Expert note: Oracle licence calculations are often owned by one or two individuals who hold the institutional knowledge of how the calculation was performed. When those individuals leave or are unavailable during an audit, the organisation cannot defend its licence position effectively. Store Core Factor Table calculations, hardware inventory exports, processor model confirmations, and calculation methodology in a shared, version-controlled repository that your audit response team can access immediately if Oracle issues an audit notification.
"The Core Factor Table looks simple — multiply cores by a factor. But the errors we find in audits stem from wrong processor identification, incorrect VMware partitioning assumptions, and cloud calculation methods. Every one of those errors costs real money." — Fredrik Filipsson, Redress Compliance
Interpreting Your Assessment Score
Count fully compliant items. Unknown answers should be treated as gaps for scoring purposes.
17–20
Strong Position
Controls mature. Schedule annual review to maintain as your estate evolves.
12–16
Moderate Exposure
Material gaps identified. Prioritise HIGH-risk items immediately and commission an independent review within 90 days.
0–11
High Exposure
Significant risk present. Do not engage Oracle commercially until independent specialists have assessed your position. Contact Redress immediately.
Why Core Factor Accuracy Is Critical in 2026
Oracle's processor licence audit methodology has become increasingly sophisticated. LMS scripts now automatically enumerate physical processor models, core counts, virtualisation configuration, and — in cloud environments — instance types. The days of self-reported estimates are over: Oracle will validate your calculations against hardware-level data. An error of even one processor generation in your Core Factor Table lookup can create a licence gap worth tens of thousands of pounds per processor in back-billing.
The 2026 Core Factor Table updates confirm that modern Intel Xeon 6-series and AMD EPYC 5th generation processors carry favourable 0.5 factors. Organisations proactively upgrading to these architectures stand to reduce their Oracle licence count significantly — potentially by 25–50% compared with legacy Intel or SPARC deployments. However, capturing this benefit requires both the hardware change and a corresponding update to your licence position, which must be documented before an audit to be defensible.