The privacy control that quietly buys an Oracle option
The Data Masking and Subsetting Pack is a paid Oracle Database option. It runs through Enterprise Manager, it is not part of Advanced Security, and Oracle can see that you used it. Almost every exposure we find started with a DBA doing the right thing for privacy and the wrong thing for the license: the pack installs with Enterprise Manager, the menu is visible to any administrator, and no purchase order is required to click it.
Prepared by Redress Compliance · August 9, 2026 · Oracle advisory. Based on roughly 20 to 30 Oracle estates reviewed 2024 to 2025.
Executive summary
It is a separately licensed Enterprise Edition option, and the matching quantity rule is what surprises people.
The pack lists at 11,500 dollars per processor, 230 per Named User Plus, 22 percent support at 2,530 per processor per year, and it is licensed at the same quantity as the database it runs against, not for the cores that happened to run the job.
You cannot license two processors of the pack on a sixteen processor machine because the masking job only used two cores, which is why where you run masking matters far more than how often you run it.
It runs on Enterprise Edition only, and Enterprise Manager, itself free, keeps the record of which packs you opened.
The scope is wider than the masking run, and the discovery step alone counts as usage.
The pack does four separately priced things, not two: masking irreversibly replaces sensitive values in a copy, subsetting builds a smaller referentially intact copy.
And before either can happen Enterprise Manager builds an application data model that discovers sensitive columns, which is itself a licensed feature.
A team that ran discovery, looked at the sensitive column report, and then decided not to mask anything has still used the pack. It is not Advanced Security: that option protects live production through encryption and redaction at 15,000 dollars per processor, while this pack transforms copies.
Different problem, different code path, different price on the same list.
Masking during a Data Pump export drags production into scope, and one dropdown decides the number. Enterprise Manager can mask in the database or mask during an export, and the second mode executes the masking against the source database rather than a clone.
If that source is production, production is now a pack target: on a 16 processor production estate that one choice is 184,000 dollars of list exposure instead of 23,000 on a two processor staging clone.
The cheapest compliant design is a single small masking staging database, cloned from production and masked in place, and even with its own Enterprise Edition at 2 times 47,500 the containment argument survives contact with a CFO, which is more than most licensing arguments manage.
Oracle's own detection script is the same evidence an auditor collects, so run it before Oracle does.
The options_packs_usage_statistics.sql script from My Oracle Support Doc ID 1317265.1 reports option and pack usage in the shape Oracle's review teams use, reading from DBA_FEATURE_USAGE_STATISTICS, which the MMON process samples weekly and writes permanently.
In roughly 6 out of 10 estates that masked non production data, the pack was not licensed on the databases where it ran, with a first usage date typically two to four years back, and that history sets the backdated support clock.
Self discovery converts an audit conversation into a purchasing conversation, and the price difference is not marginal: options attached to a renewal clear 60 percent or more off list, options attached to a settlement clear 0 to 30.
The claim Oracle brings to the meeting
| Processors on the database | Pack license | Annual support | Three years backdated | Opening claim |
|---|---|---|---|---|
| 2 | 23,000 | 5,060 | 15,180 | 38,180 |
| 4 | 46,000 | 10,120 | 30,360 | 76,360 |
| 8 | 92,000 | 20,240 | 60,720 | 152,720 |
| 16 | 184,000 | 40,480 | 121,440 | 305,440 |
| 32 | 368,000 | 80,960 | 242,880 | 610,880 |
Those are list numbers on one option, on one database. Multiply by the number of databases where masking ran and you have the reason this quiet pack shows up in seven figure findings.
The matching quantity rule is the multiplier: options license to the same level and quantity as the database program they run with, so if a server carries 16 processor licenses of Enterprise Edition, the pack is 16 processors as well, whatever the job actually touched.
The support line is the part that never goes away, because a settlement priced at a poor discount raises your baseline every year, forever, at the annual uplift. Verify the current numbers on the Oracle Technology Price List before you build a business case.
How to check whether you are already using it
- Run the script before Oracle does: options_packs_usage_statistics.sql from Doc ID 1317265.1 on every Enterprise Edition database, and read the FEATURE_USAGE column carefully, because it distinguishes current use from past use from known false positives.
- CURRENTLY USED means the feature was seen in the most recent sample; assume Oracle will price it. PAST USAGE is still chargeable in Oracle's view, and the first usage date drives how far back the claim reaches.
- BUG is Oracle itself flagging a recording as a defect; these are winnable, and they are why you never accept a raw feature usage report as a bill. NO CURRENT USAGE is the clean result you are trying to be able to prove.
- Read DBA_FEATURE_USAGE_STATISTICS like an auditor: DETECTED_USAGES separates an accident, one sample, from a deployment, forty; FIRST_USAGE_DATE sets the backdated support demand; a documented clean stop is a real argument on price. Never try to clear the history, because deleting evidence after a notice destroys the credibility you will need.
- Pull the Enterprise Manager side too: export the Management Pack Access grid per target, the masking definitions library and application data models with creation dates, and job history including failed runs, because a failed run still records intent and target. The interpretation traps sit in the LMS script output guide.
Oracle options and management packs
The separately licensed options and packs that ship enabled by default, how usage is detected, and the strip and prove playbook.
Get the white paper →Where the pack executes is the whole question
The boundary follows execution, not intent: every database the pack operated against is in scope at the full licensed quantity of that database.
If discovery, subsetting or masking ran against a database, that database is in scope; a production source you read from during a masking export is in scope; a clone you masked in place puts only the clone in scope.
The cheapest compliant design is therefore a single small masking staging database, cloned from production and masked in place, with the masked copy distributed onward.
That staging server still needs Enterprise Edition, so budget 2 times 47,500 for the database as well, because there is no free test or development right in the Oracle Master Agreement and the only no cost path is a personal developer license that does not cover a shared staging environment.
Virtualization changes the processor count but not the rule: if the staging database runs on VMware or another soft partitioned platform, Oracle counts processors host wide rather than per virtual machine.
So a two virtual CPU masking server on a large cluster can be counted across the whole cluster, which interacts badly with pack licensing.
Read the partitioning policy and the virtualized environments guide before you place the staging database.
The cloud alternative has its own boundary: for databases in Oracle Cloud, Data Safe provides masking under the cloud service model rather than under this pack, and rights do not travel in either direction.
So an on premises pack does not entitle Data Safe masking and Data Safe usage does not cover an on premises database you masked with Enterprise Manager.
Two products, two contracts, two audit questions, and the safest non production environment in the estate can still be the largest compliance gap in it.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across Oracle data masking reviews, 2024 to 2025
Across roughly 20 to 30 Oracle estates Fredrik Filipsson reviewed in 2024 and 2025, masking features were in use far more often than they were licensed, and the cause was almost never bad faith. It was a privacy program that arrived faster than the licensing conversation.
The common advice makes it worse: the standard line is that masking is a security best practice, so turn it on and sort the paperwork out later. We disagree, and not because we care less about privacy:
Estates masking non production data where the pack was not licensed on the databases it ran against. Not one had a written record of which databases were in pack scope.
Options attached to a renewal commonly clear 60 percent or more off list; options attached to a compliance settlement clear 0 to 30, with support quoted from the higher net for the life of the contract.
The mistake is treating the pack as the only way to reach the outcome. Masking is a data engineering result, not an Oracle product, and the pack is Oracle's tooling for producing it, with a graphical library, sensitive column discovery and referential integrity handling.
If your requirement is one nightly refresh of two systems, hand written transformation SQL and Data Pump with SAMPLE and QUERY get you most of the way with no option at all; if your requirement is forty applications, hundreds of tables and auditable repeatability.
Buy the pack deliberately and license the staging database it runs on.
What you must not do is drift into the middle, use the pack casually, license nothing, and discover the bill three years later. Teams also confused the pack with Advanced Security and assumed encryption rights covered masking; they do not, and Oracle prices the two differently.
Oracle will usually offer to make a finding disappear inside a larger commitment, a cloud spend agreement, a ULA, or a renewal with a support uplift, so the pack becomes the reason for a deal ten times its size: judge that offer on the whole package, fix the evidence first, then talk about the deal.
The related option discipline sits in the Diagnostics and Tuning Pack guide and the Database Vault guide.
Your first five moves
- Find out what is true today: run options_packs_usage_statistics.sql on every Enterprise Edition database, the afternoon of work that converts an audit conversation into a purchasing one.
- Turn the pack off where you have not bought it: the Management Pack Access page disables pack access per target, removing the menus and the temptation in one move.
- Restrict who can create masking definitions to a named, small group of Enterprise Manager roles, and add a licensing check to the change approval template for any new pack or option.
- Contain masking on a single small staging clone, masked in place, never during an export from production, keeping the boundary that separates 23,000 dollars from 184,000.
- Re run the usage script quarterly and file the output, because twelve dated clean reports are a far better answer to an audit letter than a memory. The Oracle practice runs the position with you.
Frequently asked questions
Is the Oracle Data Masking and Subsetting Pack a paid option?
Yes. It is a separately licensed Enterprise Edition option at 11,500 dollars per processor or 230 per Named User Plus, plus 22 percent annual support at 2,530 per processor per year. It runs through Oracle Enterprise Manager, which is itself free, and it does not run on Standard Edition 2.
It is not part of Advanced Security, which is a different option at 15,000 dollars per processor covering encryption and redaction of live production data rather than transformation of copies.
How is the Data Masking Pack licensed across processors?
By the matching quantity rule: the pack is licensed to the same level and quantity as the database program it runs with, not for the cores that happened to run the job. If a server carries 16 processor licenses of Enterprise Edition, the pack is 16 processors as well.
You cannot license two processors of the pack on a sixteen processor machine because the masking job only used two cores, which is why where you run masking matters more than how often.
Does masking during a Data Pump export affect licensing?
Significantly. Enterprise Manager can mask in the database or mask during an export, and the export mode executes the masking against the source database rather than a clone.
If that source is production, production becomes a pack target: on a 16 processor production estate the pack liability is 184,000 dollars at list, against 23,000 for the same masking run on a two processor staging clone. Masking makes the data safe; it does not make the license appear.
How do I check if we are already using the Data Masking Pack?
Run Oracle's own script, options_packs_usage_statistics.sql from My Oracle Support Doc ID 1317265.1, against every Enterprise Edition database, and read the FEATURE_USAGE column, which distinguishes CURRENTLY USED from PAST USAGE from BUG from NO CURRENT USAGE.
Then export the Enterprise Manager Management Pack Access grid, the masking definitions library, and job history. Assemble the same artifacts an auditor would, first, and own the narrative. Never try to clear the usage history.
Does the Data Masking Pack cover non production databases too?
The clone you mask still needs full licensing. There is no free test or development right in the Oracle Master Agreement, so a shared staging database carries Enterprise Edition plus the pack, and that cost belongs in the business case on day one.
The cheapest compliant design is a single small staging database, cloned from production and masked in place, which keeps only the clone in scope rather than dragging production in through an export.
How much discount can you get on the Data Masking Pack?
It depends entirely on timing.
Options attached to a new purchase or renewal commonly clear 60 percent or more off list in a competitive negotiation, while options attached to a compliance settlement clear 0 to 30 percent, with support then quoted from the higher net value for the rest of the contract's life.
That asymmetry is the practical reason to run the usage script now: self discovery converts an audit conversation into a purchasing conversation, and the price difference is not marginal.
