Large insurance groups like Canada Life typically operate Oracle environments that grew organically over decades — acquired through M&A, expanded during digital transformation, and migrated partly to cloud with licensing assumptions that no longer match Oracle's current rules. The result is a compliance position that looks stable on the surface but carries material exposure across virtualisation, feature usage, Java, and user counting.
This checklist covers the 20 controls that matter most in a structured Oracle licensing assessment for insurance and financial services organisations. Each item includes an expert commentary note drawn from our LMS advisory practice. Work through the list systematically — any single red flag here can represent six or seven figures in unbudgeted liability.
Every Oracle product deployed in your environment — including Database Enterprise Edition, Standard Edition 2, Middleware, WebLogic, SOA Suite, Identity Manager, and all options — must be inventoried with version numbers, edition types, and deployment locations. Shadow IT deployments and inherited assets from acquisitions are the most common gaps. Oracle LMS discovery tooling will find installations that your internal CMDB has missed.
Your legal entitlement — the right to run Oracle software — derives from signed agreements. Collect every Oracle ordering document, Master Agreement, and support renewal for the past 10 years. Reconcile these to current deployments. Common gaps include licenses purchased through resellers without proper Oracle assignment, ULA agreements where the certification window was missed, and support renewals that do not align with the underlying perpetual license grant.
Oracle has over 20 different licence metrics, and the wrong metric applied to a deployment can create significant shortfalls. Database Enterprise Edition uses Processor or Named User Plus (NUP) metrics — but the minimum NUP calculation per processor often exceeds the actual user count, meaning NUP is not always cheaper than Processor licensing as organisations assume. Middleware products use Application User, Processor, Employee, and other metrics that vary by product line and version.
Oracle charges by physical processor core, not socket or VM. The number of licences required = number of physical cores × Oracle Processor Core Factor (0.5 for Intel/AMD multi-core, 1.0 for SPARC T-series, etc.). You must document every server running Oracle: make, model, processor family, core count, and the applicable core factor. For virtualised environments, this calculation is further complicated by cluster scope requirements.
Oracle's virtualisation policy requires that if Oracle software runs on any server within a VMware cluster, you must license every physical core in that entire cluster — not just the VMs or hosts where Oracle is deployed. This is Oracle's most aggressively enforced policy and the single largest source of audit exposure we encounter in insurance sector assessments. A single Oracle VM on a 20-node cluster requires licensing all 20 servers at maximum core count.
If you have isolated Oracle workloads onto dedicated physical hardware, you must document this isolation in a way that will withstand Oracle LMS scrutiny. Required evidence includes vCenter configuration exports showing cluster membership, network diagrams confirming physical separation, change control records showing isolation was established, and a current attestation that no Oracle VMs migrate outside the isolated cluster. Oracle places the burden of proof firmly on the customer.
Oracle allows use of its software on AWS and Azure under its Authorised Cloud Environments (ACE) policy, but the licensing metric changes from physical cores to vCPUs — at a ratio of 2 vCPUs = 1 processor licence. This ratio improves the economics in some cases but creates risk if you deployed assuming on-premises core factors apply, or if your cloud environment uses hardware tenancies or bare metal instances where different rules apply. Oracle Cloud Infrastructure has its own licensing considerations.
Oracle Database Enterprise Edition does not include any options in its base price. Each option — Partitioning, Advanced Compression, Advanced Security, Label Security, Diagnostics Pack, Tuning Pack, Real Application Clusters, Active Data Guard — is an additional product requiring a separate licence. DBA teams frequently enable these options for testing, troubleshooting, or performance tuning without realising they have triggered a licence requirement. Oracle's LMS tooling captures feature usage with timestamps.
Oracle Enterprise Manager's Automatic Workload Repository (AWR) reports, SQL Tuning Advisor, and Automatic Database Diagnostic Monitor (ADDM) are all Diagnostics Pack or Tuning Pack features — not included in Oracle Database EE. Accessing these through the OEM console constitutes usage, even if you are just reviewing historical data. Review every DBA access log against licensed pack entitlements, and disable access to unlicensed features in OEM configuration.
Oracle RAC is a widely used high-availability option in insurance sector deployments due to regulatory requirements for system availability and DR. Each node in a RAC cluster must be licensed, and the node count × core count × core factor = licence requirement per cluster. RAC entitlements purchased years ago may not reflect current node counts after infrastructure expansion. Cross-reference your RAC entitlements against current cluster topology.
If you licence by Named User Plus metric, reconcile your NUP licence quantity against every individual who can access Oracle — including employees, contractors, consultants, and service accounts used for system-to-system integrations. Apply the 10-per-processor minimum: you must licence at least 10 NUPs per Processor metric even if fewer users exist. NUP licences that do not meet minimum quantities create shortfalls that Oracle identifies in automated audit scripts.
Oracle counts any person who accesses Oracle data — directly or through a middleware layer, application server, or integration platform — as a Named User Plus for licensing purposes. In insurance companies, this includes policy administration system users, claims management platform users, actuarial modelling tool users, and batch job service accounts. If these users are not covered by Processor licensing, each must be counted as an NUP. Map every application that touches Oracle and trace through to the user population.
Oracle changed Java SE licensing in January 2023 to a per-employee subscription model — meaning any organisation with employees must purchase licences for all employees, not just those using Java. Prior to this change, Java SE 8 under older subscription terms applied per named user. Insurance organisations that have not assessed their Java posture since January 2023 may be significantly under-licensed. The new model dramatically increases costs for large employers.
Java SE 8 update 202 and earlier versions remain available for development use without a commercial licence. However, any update from 202 onward requires a commercial subscription. Many insurance organisations run legacy Java applications that rely on specific Java 8 micro-versions, creating a risk that patch management has inadvertently taken them into commercial territory. Audit every Java installation for version and update level — and assess whether the application requires commercial updates to stay supported.
Oracle requires that DR environments be fully licensed unless a specific exception applies. The Data Guard physical standby allowance permits a single passive standby instance without additional processor licences, but only if it runs no active workloads. Active standby configurations (including Active Data Guard), logical standbys, and any scenario where the standby processes queries requires full licensing. Insurance companies under regulatory requirements for DR often run active-active configurations that violate this boundary.
Oracle does not offer a blanket "development use is free" exemption for commercial deployments. Development and test instances of Oracle Database, WebLogic, and other products require valid licences unless covered by a specific provision (e.g., a Technology Network Developer licence for personal, non-production development). In large insurance organisations, development environments typically run dozens of Oracle instances — often on the same servers as production or on infrastructure that creates the same VMware cluster licensing scope issue.
An Oracle Unlimited Licence Agreement (ULA) requires a formal certification process at expiry where you declare all deployments and receive a perpetual licence grant for that quantity. Organisations that certify without a thorough pre-certification review often declare too many deployments (raising their perpetual licence baseline) or miss optimisation opportunities to reduce future support costs. Insurance organisations with ULAs covering Database or Middleware products should begin pre-certification planning no later than 12 months before ULA expiry.
Every corporate acquisition that brings Oracle software into your environment is a potential audit trigger and a licence management obligation. Oracle agreements are not automatically transferable — if an acquired company ran Oracle under agreements that named a different legal entity, you may be operating Oracle without valid entitlement. The acquiring entity must either novate the acquired agreements or obtain new licences. In insurance sector consolidation, this is a recurring issue in mid-market and specialty insurer acquisitions.
When Oracle initiates an audit, the first 30 days determine your strategic position. A well-prepared organisation acknowledges the audit, engages independent legal and licensing advisors, controls what data Oracle's LMS scripts collect, and sets a measured timeline for data provision. An unprepared organisation provides rushed, unreviewed data that overstates its exposure and then negotiates from weakness. Document your Oracle audit response procedure before you need it — not after Oracle's letter arrives.
Oracle licensing compliance is not a point-in-time event — it is a continuous operational requirement. Insurance organisations need a designated Oracle licence management owner with authority to engage IT, procurement, legal, and finance. A quarterly reconciliation cycle comparing deployed software against current entitlements catches drift before it becomes audit exposure. Any infrastructure change — server upgrades, virtualisation changes, new Oracle product deployments, cloud migrations — should trigger a formal licence impact assessment before implementation.
Download the Oracle Audit Defence Kit
Step-by-step response playbook, LMS data control guidance, and settlement strategy for Oracle audits.How to Use This Assessment
Work through each of the 20 controls above and assign a status of Green (fully compliant, documented), Amber (partial compliance or undocumented), or Red (non-compliant or unknown). Any Red or Amber rating on items flagged as High Risk should be treated as an immediate priority. Insurance organisations typically find between four and eight controls in Amber or Red status on first assessment — which is entirely normal given the complexity of Oracle's licensing rules, but which requires a structured remediation plan.
For Amber items, the primary task is documentation and evidence-gathering. For Red items, you need to assess whether remediation (purchasing missing licences, removing unlicensed software, or establishing valid isolation) is achievable before an Oracle audit materialises. An independent licensing assessment by a buyer-side Oracle advisor — one with no commercial relationship with Oracle — will give you a defensible position and a remediation roadmap.
Why Insurance Sector Oracle Estates Are Particularly Complex
Insurance and financial services firms face a combination of Oracle licensing challenges that other sectors encounter individually but rarely together. Regulatory requirements for high availability drive Active Data Guard deployments that require separate licensing. Long-running M&A activity across the insurance sector creates accumulated licensing debt from acquired entities. Actuarial modelling, claims systems, and policy administration platforms often rely on indirect database access through application layers — creating large NUP exposure for organisations using that metric. And the industry's reliance on Java for legacy applications means the 2023 Java licensing changes carry outsized impact here.
The Canada Life assessment framework addresses all of these dimensions systematically. Running this checklist as an annual exercise, with a qualified adviser review every two to three years, is the most cost-effective approach to maintaining a defensible Oracle licence position in a complex insurance estate.
Request an Independent Oracle Licensing Assessment
Buyer-side only. No Oracle commercial relationship. Confidential.