Oracle Label Security (OLS) is an advanced Oracle Database option that provides row-level data protection by assigning classification labels to data. It is not included with standard Oracle Database Enterprise Edition licences — it requires a separate licence. This guide covers the complete licensing structure, cost model, on-premises vs cloud considerations, common compliance pitfalls, and optimization strategies for ITAM professionals and enterprise IT leaders.
Oracle Label Security (OLS) is a security feature of Oracle Database Enterprise Edition that enforces multi-level access control within the database. It enables organisations to assign a classification label — such as Public, Confidential, Secret, or Top Secret — to each data row and restrict access based on a user's clearance level. In practice, this means users only see the data they are authorised to see, even when querying the same table as others.
OLS builds on Oracle's built-in Virtual Private Database (VPD) technology, providing a ready-made framework for implementing label-based security policies without requiring custom coding. For enterprises that need granular data security — particularly in government, defence, financial services, and healthcare — OLS can be a crucial tool.
However, OLS comes at a significant additional licensing cost. Understanding exactly when a licence is required, what it costs, and how to avoid common compliance traps is essential for any ITAM professional managing an Oracle estate.
"Oracle Label Security is one of the most commonly under-licensed Oracle Database options we encounter in assessments. The problem is that OLS can be enabled inadvertently — a DBA creates a label policy for testing, the LBACSYS schema gets activated as part of another configuration, or Database Vault activates OLS under the hood. Oracle's audit scripts detect all of these scenarios. If you're running Enterprise Edition and haven't specifically verified that OLS is not enabled, you may already have a compliance exposure you don't know about."
— Fredrik Filipsson, Co-Founder, Redress ComplianceOracle Label Security is a sensible choice for enterprises that handle sensitive or regulated data that must be compartmentalised. Typical use cases include a multinational bank ensuring regional data managers can only view customer records for their region, a government agency labelling data by classification level (Unclassified, Confidential, Top Secret) and restricting access accordingly, healthcare organisations enforcing patient data segregation by department or sensitivity, and defence contractors implementing mandatory access controls required by government contracts.
These use cases demonstrate OLS's ability to simplify compliance with data privacy laws and internal security policies by enforcing controls at the database level rather than relying solely on application logic.
Read about related security options: Oracle Database Vault Licensing | Oracle Advanced Security Licensing
Oracle Label Security is licensed as a separate optional product for Oracle Database Enterprise Edition. It is not included in the on-premises base Enterprise Edition licence — you must explicitly licence OLS if you use it.
OLS can be licensed either by Processor or by Named User Plus (NUP), mirroring the database's licence metric. If your database is licensed per processor, you must licence OLS for each processor on that database server. If your database is licensed per user, you need to purchase the equivalent number of NUP licences for OLS — with Oracle's standard minimums of 25 NUP per processor for Enterprise Edition.
Oracle's list price for Label Security is approximately $11,500 per processor (full upfront licence cost, plus annual support at ~22% of the licence cost — approximately $2,530 per processor per year in ongoing support). For Named User Plus, the cost is approximately $230 per named user. Enterprise discounts or large agreements can reduce these prices, but OLS remains a significant investment — especially for servers with many cores.
| Environment / Edition | OLS Licensing Requirement |
|---|---|
| Oracle Database Enterprise Edition (on-premises) | Extra cost option — must be licensed separately per processor or per NUP |
| Oracle Database Standard Edition 2 | Not available — OLS cannot be used with Standard Edition |
| Oracle Database Personal Edition / Express (Free) | Included — full OLS functionality at no charge (single-user/dev environments) |
| Oracle Database Appliance (on-premises EE) | Extra cost — OLS must be licensed as an EE option |
| Oracle Exadata (on-premises EE licence) | Extra cost — OLS must be licensed as an EE option |
| Oracle Cloud DB Service — EE (Base/BYOL) | Extra cost — not included in base EE service tier |
| Oracle Cloud DB Service — EE High Perf / Extreme | Included — OLS included with High/Extreme Performance tiers |
| Oracle Exadata Cloud Service / Cloud@Customer | Included — OLS included with Exadata cloud subscriptions |
⚠️ Key rule: If OLS is used in any capacity on a database, the entire database instance must be licensed for it. You cannot enable OLS for just one schema or subset of users. In a multitenant architecture, if any PDB uses OLS, the option must be licensed at the CDB level for all processors. In a RAC cluster, all nodes must be licensed.
Every Oracle database server that uses OLS must be fully licensed. If OLS is enabled on a production database, you pay for each processor on that server. In a RAC cluster, every node's processors must be licensed. Standby or disaster recovery instances that are open for use with OLS-protected data should also be licensed. Oracle's licence rules specify that licensing is tied to the installed/available feature — not just actual usage at a given moment.
On-premises, OLS is often purchased alongside Database Vault and Advanced Security as part of a security toolkit — but each is a separate option licence requiring its own purchase.
Oracle has incentivised cloud adoption by bundling many options into certain service tiers. If an enterprise opts for Oracle Cloud Database with the High Performance or Extreme Performance tier, OLS is included in the bundled features — along with Database Vault, Partitioning, and other options. This can simplify cost management: the subscription rate covers everything, and you don't need to count cores and buy perpetual licences.
However, if you choose a lower-cost cloud service (or use BYOL), you must ensure you have OLS licences or upgrade the service tier. Enterprises with hybrid environments should avoid double-payment: if you move a workload to the cloud, consider reassigning or terminating unused on-premises licences to optimise costs.
"Cloud can effectively include Oracle Label Security in the subscription cost — but only if you choose the right service level. The difference between the base EE cloud tier and the High Performance tier can be significant, so you need to model the total cost including all options you actually need. In some cases, upgrading to High Performance is more cost-effective than licensing individual options separately. In others, BYOL with existing on-premises licences is the better path. The analysis depends entirely on your specific environment and contract terms."
— Fredrik Filipsson, Co-Founder, Redress ComplianceA comprehensive guide to understanding your Oracle licensing position — covering database options, cloud migration considerations, audit preparedness, and cost optimisation strategies.
Download Whitepaper →| Pitfall | What Happens | How to Avoid It |
|---|---|---|
| Accidental enablement | Oracle Database includes OLS binaries and default schemas (like LBACSYS). A DBA or developer can create a label security policy for testing without formal approval. Even brief use triggers a licensing requirement. Oracle LMS scripts detect OLS policies or related objects during audits | Regularly scan databases for label security configurations — policies, labels, OLS-specific user accounts. Require formal approval before enabling any extra-cost option |
| Assuming Database Vault covers OLS | Database Vault automatically activates OLS under the hood for Vault's own mechanisms. But a DB Vault licence does not entitle you to create your own label security policies. Oracle explicitly states that using OLS for your own labelling requires a separate OLS licence | Treat OLS and Database Vault as separate options — each requiring its own licence. If you have DB Vault, do not assume you can also use OLS for your data without a separate purchase |
| Multitenant partial deployment | In a multitenant database, you cannot licence OLS for just one PDB. If any PDB uses OLS, all the host's processors must be licensed at the CDB level. Similarly, in RAC, if OLS is active on a clustered database, all nodes must be licensed | Do not assume you can enable OLS for one PDB and avoid licensing the entire CDB. Plan deployments so OLS-required workloads are consolidated on dedicated, properly licensed containers |
| Cost underestimation | OLS costs add up quickly on modern multi-core servers or large clusters. Budgets often account for base database licences but overlook options. At audit time, the organisation faces a substantial true-up bill | Always review which Oracle features are in use or enabled. Use Oracle's Database Feature Usage Statistics view and audit scripts internally before Oracle does |
| Ignoring support renewals | Annual support fees (~22% of net licence cost) are required to stay compliant and receive updates. Dropping support can lead to non-compliance if you upgrade database versions or need patches on an unsupported licence | Include ongoing support costs in TCO calculations. Never drop support on licences you're actively using |
⚠️ Audit risk: Unlicensed OLS use — even inadvertent enablement on a single table — can result in non-compliance findings during an Oracle audit. Oracle's LMS scripts will detect OLS policies, labelled data, and the LBACSYS schema. The consequence: a demand to purchase licences for the period of unlicensed use, potentially with back-support fees. Run internal checks before Oracle runs theirs.
Since licensing is per processor, running all workloads that need OLS on a dedicated server or cluster contains the scope. Rather than enabling OLS on many databases enterprise-wide, consider centralising the sensitive data that truly requires labelling onto fewer databases. Fewer licensed environments = lower costs.
Enterprises negotiating an Oracle ULA or cloud consumption agreement should evaluate including OLS. If OLS is part of a ULA contract, you can deploy it widely during the ULA term without counting licences. Oracle sales often bundle OLS with other security options (Advanced Security, Database Vault) at a discounted rate as part of larger deals.
Oracle's native VPD (Fine-Grained Access Control) can achieve similar row-level security outcomes without additional cost. The trade-off: OLS provides a pre-built policy framework, while VPD requires manual policy writing for each table. Depending on your team's expertise, using VPD or application-layer security logic might be viable for smaller-scale needs — saving on licence costs. Compare the implementation effort vs the licensing fee.
Moving a workload that requires OLS to Oracle Cloud's High Performance tier might be more cost-effective than licensing the option on-premises — especially for short-term projects. Always conduct a cost comparison over your planned time horizon: cloud subscriptions versus perpetual licences and support.
Use Oracle's provided tools or third-party scripts to regularly check if OLS has been enabled anywhere in your environment. If an internal audit finds unapproved OLS usage, take action to either remove the feature or procure licences before Oracle's official audit finds them. Early detection turns a costly surprise into a manageable budget item.
Oracle database options like Label Security, Database Vault, and Advanced Security are among the most common audit findings. This whitepaper reveals the hidden risks and how to address them proactively.
Download Whitepaper →| Recommendation | Detail |
|---|---|
| Conduct a feature inventory | Proactively identify which Oracle Database features and options (like OLS) are enabled or in use across all database instances. This inventory is the foundation for compliance and cost optimisation |
| Educate and govern usage | Institute a governance process where DBAs and architects must get approval before implementing Oracle Label Security. Training staff on which features incur extra licensing prevents accidental use |
| Align licensing with database metric | Always match OLS licences to your database licence metric (processors or NUP) and quantities. This ensures full coverage and avoids licensing gaps that Oracle identifies during audits |
| Consider security bundles | When possible, negotiate OLS as part of a larger security bundle (with Database Vault, Advanced Security, etc.) during Oracle contract discussions. Oracle may offer better discounts when multiple options are purchased together |
| Leverage Oracle Cloud if feasible | Deploy OLS-required workloads on Oracle Cloud service tiers that include the option. This shifts the cost to a predictable subscription and might reduce upfront spend |
| Review periodically | Treat OLS licensing as a living aspect of your IT portfolio. Regularly review whether it's still needed in each instance, and whether the usage justifies the ongoing cost (especially support renewals) |
| Plan for audits with confidence | Maintain thorough documentation of where and why OLS is used, along with proof of licences. A well-documented environment makes Oracle audits far less painful and demonstrates good faith in licence management |
| Explore alternatives for new projects | For new applications requiring row-level security, evaluate whether Oracle's built-in VPD or alternative database technologies can meet requirements without additional licensing. Use OLS only when it meets a requirement that can't be easily met otherwise |
Not sure whether Oracle Label Security, Database Vault, Advanced Security, or other options are enabled in your environment? Our licensing assessment identifies every Oracle feature in use, quantifies compliance exposure, and develops optimisation strategies — before Oracle's audit team does.
From database options bundling to ULA negotiations to audit defence — the 10 strategies that consistently deliver the best outcomes for enterprises negotiating with Oracle.
Download Whitepaper →Full deployment inventory, compliance verification, and cost optimisation across databases, options, middleware, applications, and Java.
Learn More →Expert defence against Oracle LMS and GLAS audits — protecting your position on database options, licensing metrics, and compliance findings.
Learn More →Independent advisory for Oracle purchases, renewals, and ULA negotiations — including security option bundling and pricing optimisation.
Learn More →