Oracle Data Masking and Subsetting Pack licensing. What it costs and which databases need it.

The pack is a paid Enterprise Edition option at $11,500 per processor. Oracle requires it on the source database the data comes from, at that database's full quantity, while the staging server and masked copies need no pack.

What does the Oracle Data Masking and Subsetting Pack cost?

The pack is a separately licensed option for Oracle Database Enterprise Edition. It lists at $11,500 per processor or $230 per Named User Plus, and support adds 22 percent a year, which is $2,530 per processor. Oracle does not sell it for Standard Edition 2.

It runs through Oracle Enterprise Manager Cloud Control, whose base product is free, so the masking menus appear for any administrator whether or not the pack was bought. Most exposure we find started with a DBA doing the right thing for privacy and the wrong thing for the license.

What exactly is inside the pack?

One price covers every component Oracle lists for the pack, and using any one of them is use of the pack. Confirm current figures on the Oracle Technology Price List before you build a business case.

• Application Data Modeling. Enterprise Manager scans the schema, finds sensitive columns and records the relationships between tables. A team that ran discovery, read the sensitive column report and then masked nothing has still used the pack.
• Masking formats library and masking definitions. The reusable formats and the definitions that apply them to columns. Masking replaces sensitive values in a copy, and the change cannot be reversed.
• Subsetting definitions. These build a smaller copy of the data that keeps referential integrity, so test systems get a coherent slice instead of the whole database.
• Command line and templates. The Enterprise Manager command line verbs for the same functions, plus data model accelerators and masking templates for select versions of E-Business Suite and Fusion Applications.
• Restricted gateway rights. Six Database Gateways (APPC, DRDA, Informix, SQL Server, Sybase, Teradata), usable only to stage non Oracle data into a separately licensed Oracle Database for masking. Any other use of those gateways needs full licenses.

Is the masking pack part of Advanced Security?

No. Advanced Security, at $15,000 per processor, protects live production data through Transparent Data Encryption and Data Redaction, while the masking pack transforms copies. Owning one gives you no rights to the other. The Advanced Security licensing guide covers that option in detail.

Which databases need a Data Masking and Subsetting Pack license?

The source database. Oracle's Licensing Information User Manual says the pack must be licensed for the source database server, meaning the database the data originates from. It also says there is no requirement to license the pack for the staging database where masking and subsetting run, or for copies made of the masked database.

For most customers the source is production. The pack quantity is therefore set by the licensed size of each production database that feeds a masking or subsetting job, whatever server the job itself executes on. Three production databases feeding test data means three license lines, each at that database's full quantity.

Does a small masking server keep production out of scope?

It does not, and a lot of published guidance gets this wrong. The usual argument is to clone production onto a two processor staging database, mask it there, and pay $23,000 for the pack instead of $184,000 on a 16 processor production source. Oracle's wording does not support that saving.

The data originates in production, so production carries the pack at 16 processors and the staging clone carries none. The staging design is still worth building: it keeps masking workload off production, gives you one controlled place where definitions run, and means only masked copies travel onward.

Does masking during a Data Pump export change the license?

Enterprise Manager offers two modes. In database masking works on a cloned copy and masks it in place. Masking during export applies the formats while Data Pump exports from the source, so the dump file never holds clear values, and the masking executes against the source database rather than a clone.

Both modes read from the same source, so the license requirement is identical. The difference lies in where the usage record lands. Export mode puts pack activity directly on production, where an auditor's scripts look first, so choose the mode for security and workload reasons and license the source either way.

What does the staging database itself need?

A database license. The pack is not required on staging, but the Oracle Database running there is, and there is no free test or development right in the Oracle Master Agreement. The only no cost path is a personal developer license, which does not cover a shared staging environment.

Because the pack is an Enterprise Edition product, the staging server normally runs Enterprise Edition. Budget 2 times $47,500, which is $95,000 at list plus $20,900 a year in support for two processors, and put it in the business case on day one.

• Virtualized staging. On VMware or another soft partitioned platform, Oracle counts processors host wide, so a two virtual CPU staging server on a large cluster can be counted across the whole cluster.
• Virtualized sources. The same counting applies to production. If the source database sits on a cluster licensed host wide, the pack follows that larger quantity.
• Where to read more. Check the partitioning policy and the virtualized environments guide before you place either database.

What about Standard Edition 2 and non Oracle sources?

Both need care before anyone builds the data flow. Oracle sells the pack only with Enterprise Edition, so there is no clean way to license a Standard Edition 2 source; get Oracle's position in writing. SQL Server, DB2 or Teradata data must first be staged through the bundled gateways into a licensed Oracle Database.

What does an Oracle claim for unlicensed masking look like?

Oracle opens at list price for the pack on each database it considers in scope, plus support backdated to the first usage date. The table shows one option on one database, with three years of backdated support at 22 percent.

Multiply by the number of source databases and it is clear how this small pack ends up in seven figure findings. The support line never goes away: a settlement priced at a poor discount raises your support baseline every year you keep the pack, with the annual uplift on top.

Worked example: buying at renewal versus settling after an audit

Say a hypothetical company masks data from one production database licensed for 16 processors, running the jobs on a two processor staging clone. The pack is 16 processors on production. The table compares buying it with a renewal against settling after an audit, using discount levels from our own work.

The gap is $115,920 on one database, before any backdated support in the settlement, and 30 percent off is the best settlement outcome we see. If the production database is licensed by Named User Plus instead, the pack must match the database user count. Say that count is 400 users: at $230 each, the pack is $92,000 at list.

How do you check whether you are already using the pack?

Run Oracle's own script before Oracle does, and read it the way an auditor will. The script is options_packs_usage_statistics.sql from My Oracle Support Doc ID 1317265.1. It reads DBA_FEATURE_USAGE_STATISTICS, which the MMON process samples weekly and keeps, in the shape Oracle's review teams use.

• CURRENT_USAGE. The feature was seen in the latest sample. Assume Oracle will price it.
• PAST_USAGE. No longer active, still chargeable in Oracle's view. The first usage date decides how far back the claim reaches.
• SUPPRESSED_DUE_TO_BUG. Oracle itself flags the record as a defect. These lines are winnable, and they are the reason you never accept a raw feature usage report as a bill.
• NO_CURRENT_USAGE. The clean result you want to be able to prove, quarter after quarter.

Which columns decide the size of a claim?

DETECTED_USAGES separates an accident, one sample, from a deployment, forty. FIRST_USAGE_DATE sets the backdated support demand. A documented and dated stop is a real argument on price. Never try to clear the history: deleting evidence after an audit notice destroys the credibility you will need later.

What does Enterprise Manager record?

The database view is only half the record for this pack, because the work is driven from Enterprise Manager. Export these items before anyone asks for them:

1. The Management Pack Access grid, showing which packs are enabled on each target.
2. The masking and subsetting definitions library and the application data models, with creation dates and the source database each one points to.
3. Job history, including failed runs, because a failed run still records intent and target.

Then map every definition and job to its source database. That list of sources is your license requirement. The interpretation traps are covered in the LMS script output guide and in our note on management packs in the feature usage view.

Which mistakes do teams make when they check?

• Trusting the wrong switch. Setting CONTROL_MANAGEMENT_PACK_ACCESS to NONE does not disable masking. That parameter controls only the Diagnostics and Tuning packs; masking is controlled per target on the Management Pack Access page, as our pack access guide explains.
• Licensing the staging server. Buying the pack for the small masking server pays for a database that needs no pack and leaves the production source unlicensed.
• Reading only the database view. Definitions, data models and job history in Enterprise Manager show sources that the database report alone will not.
• Assuming encryption covers masking. Advanced Security rights do not extend to this pack, and Oracle prices the two separately.
• Checking once. A single clean report proves little. The same discipline applies to the Diagnostics and Tuning packs and to Database Vault.

What have we seen in Oracle data masking reviews in 2024 and 2025?

Across roughly 20 to 30 Oracle customers Fredrik Filipsson reviewed in 2024 and 2025, masking features were in use far more often than they were licensed. The cause was almost never bad faith. A privacy program had arrived faster than the licensing conversation.

• Unlicensed use was the norm. In roughly 6 out of 10 environments that masked non production data, the pack was not licensed for the databases involved in the masking work. Not one had a written record of which databases were in pack scope.
• History ran back years. The first usage date typically sat 2 to 4 years back, and that date set the clock for backdated support.
• Timing set the discount. Options attached to a new purchase or renewal commonly cleared 60 percent or more off list. Options attached to a compliance settlement cleared 0 to 30 percent, with support quoted from the higher net for the life of the contract.
• The finding became a bigger deal. Oracle usually offered to make the finding disappear inside a larger commitment, such as a cloud spend agreement, a ULA or a renewal with a support uplift. The pack became the reason for a deal ten times its size.

Judge that kind of offer on the whole package. Fix the evidence first, then talk about the deal.

Finding the usage yourself turns an audit conversation into a purchasing conversation, and on an Oracle option that timing is worth more than any argument about the job itself.

Why we disagree with "mask now, license later"

The standard line is that masking is basic data protection, so switch it on and sort out the paperwork afterwards. We disagree, and not because privacy matters less. Masking is a data engineering result, and the pack is only Oracle's tooling for producing it, with a graphical library, sensitive column discovery and referential integrity handling.

For one nightly refresh of two systems, hand written transformation SQL plus Data Pump with SAMPLE, QUERY and REMAP_DATA gets you most of the way with no option at all. For forty applications, hundreds of tables and auditable repeatability, buy the pack deliberately for its sources. Avoid the middle: casual use, nothing licensed, and a bill three years later.

How does data masking work for Oracle Cloud databases?

In Oracle Cloud the rights come with the cloud service. Every Enterprise Edition package of Base Database Service, from entry Enterprise Edition to Extreme Performance, includes the pack, and so does Exadata Database Service. Data Safe, which offers discovery and masking, is included at no extra cost for paid cloud databases on OCI.

Rights do not travel in either direction. 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. Treat them as separate products with separate audit questions, and record which databases each one covers.

How should you negotiate the pack with Oracle?

Settle the facts before the price. Know your source databases, their licensed quantities and their first usage dates, then decide whether you want the pack at all.

What the account team will say, and what to say back

• "Our scripts show Data Masking on your staging database, so staging needs the pack." Point to the Licensing Information User Manual, which excludes the staging server and masked copies. Then ask them to name the source databases, because that is the real conversation.
• "Every production database in Enterprise Manager is in scope." Only databases that supplied data to a masking or subsetting job are sources. Show the definitions and job history that tie each run to one database.
• "Past usage is billable at list back to the first usage date." Go through DETECTED_USAGES, bug flagged records and documented stop dates line by line. Treat backdated support as a number to negotiate, not a formula.
• "We can make this go away inside a larger cloud agreement." Ask for the pack priced on its own first, so you know exactly what the larger deal is absorbing.

Contract wording to ask for

• Named source databases. List each licensed source database and its quantity in the ordering document, so scope is not argued again at the next review.
• Staging and copy exclusion. Quote Oracle's own wording that staging servers and masked copies need no pack. Manuals change between releases, while your order stays fixed.
• Price hold for new sources. Fix the same discount for source databases added during the term; our guide to price holds and uplift caps has the wording.
• Support uplift cap. Cap the yearly increase on the pack's support line, since that line outlives the purchase.
• Release of past use. In any settlement, get a written release for pack usage up to the signature date on every database in the report.

How the answer changes with the size of your Oracle footprint

A company with one production ERP database licensed for 4 processors faces $46,000 at list. At that size, custom scripts and Data Pump often do the job, and the cheapest route may be to switch the pack off and never buy it.

A group feeding many test environments looks different. Say three production sources are licensed for 16, 8 and 4 processors: that is 28 processors and $322,000 at list before support. At that scale the pack usually earns its cost, and the value is in buying it with a renewal for a named list of sources.

What to do next

1. This month. Run options_packs_usage_statistics.sql on every Enterprise Edition database and file the output. It is an afternoon of work.
2. Map the sources. Tie every definition, data model and masking job, including failed runs, to the database the data came from.
3. Switch it off where unbought. Use the Management Pack Access page to disable the pack per target, which removes the menus and the temptation together.
4. Limit who can mask. Restrict masking definitions to a small, named group of Enterprise Manager roles, and add a licensing check to the change approval template for any new pack or option.
5. Contain the workload. Run masking on one staging clone, masked in place, and license the source databases, since the staging server needs no pack.
6. Buy on your timing. If you need the pack, price it for the named sources and attach it to your next renewal.
7. Repeat quarterly. Rerun the script and file each output, because twelve dated clean reports answer an audit letter better than memory. Our Oracle practice can build and maintain that record with you.

Frequently asked questions