Software asset management has its own international standard, ISO 19770, and a market of tools that promise to keep your Oracle estate compliant. The promise is appealing. Continuous visibility, automated entitlement reconciliation, and a defensible position when the audit notice arrives. The reality is more complicated. No tool reads Oracle licensing perfectly, some tools share data with Oracle by design, and the output of any tool is only as good as the entitlement baseline you feed it. This note explains what ISO 19770 actually covers, how SAM tools handle Oracle, and the discipline that turns a SAM investment into a negotiating asset rather than an audit liability.
1. What ISO 19770 actually covers.
ISO 19770 is a family of standards for software asset management. The headline part defines a management system for the SAM function, similar in structure to other management system standards. Other parts define data formats for software identification tags and entitlement records. The standard is about process discipline and data structure. It does not certify that any particular tool reads Oracle licensing correctly.
This distinction matters because vendors market ISO 19770 alignment as if it guarantees Oracle compliance. It does not. A SAM programme can be fully aligned to the standard and still produce a wrong Oracle position, because the standard governs how you manage data, not whether the underlying licensing interpretation is correct. The interpretation is where Oracle disputes live, and the standard is silent on it.
2. The Oracle verified tool problem.
Oracle operates a programme that designates certain SAM tools as verified for measuring Oracle deployments. On the surface this looks like reassurance. In practice it raises a control question. A tool verified by Oracle is built to measure deployments the way Oracle measures them, which means it tends to produce the Oracle maximal interpretation rather than the defensible buyer position.
Some of these arrangements also involve data sharing. The tool can transmit measurement data in a form that Oracle can request or receive. The buyer side concern is straightforward. If your compliance tool produces Oracle's interpretation and can share data with Oracle, you have built the audit case against yourself. The control principle is that the buyer owns the data and the interpretation, not the vendor and certainly not Oracle. See our processor counting note for why the interpretation matters so much.
3. What SAM tools measure well.
SAM tools are genuinely useful for the deployment side of the equation. They discover where Oracle software is installed, which versions are running, and which options and management packs have been used. The options and packs question is particularly valuable because Oracle database options generate some of the most common and most expensive audit findings, and they are easy to enable inadvertently.
A good SAM deployment gives you an early warning system for option usage, version sprawl, and unauthorised installations. Used internally and privately, this is a powerful management tool. The discipline is to treat the output as your private working data, to validate it against the contract, and never to expose it externally without review. This is the same control posture we apply across virtualization compliance.
4. What SAM tools measure poorly.
SAM tools struggle with the parts of Oracle licensing that depend on interpretation rather than measurement. Virtualization footprint is the clearest example. A tool can see where the software runs, but the licensable footprint depends on the soft partitioning argument, which is contractual rather than technical. Tools that apply Oracle's maximal interpretation will report the worst case footprint as if it were fact.
Tools also struggle with entitlement reconciliation when the entitlements are complex. Migrated licences, ULA exit certifications, named user minimums, and legacy metrics all require human interpretation that no tool applies reliably. The output is a starting point for analysis, not a compliance conclusion. The buyer who treats the tool output as truth has surrendered the interpretation to software.
5. The entitlement baseline.
Every SAM tool reconciles deployment against entitlement, and the entitlement side is where most programmes are weakest. The tool cannot read your contracts. Someone has to enter the entitlements, and that entry is only as accurate as the person who built it. Errors in the entitlement baseline produce false compliance gaps or false comfort, and both are dangerous.
The buyer side discipline is to build the entitlement baseline from the actual ordering documents and master agreement, validated by someone who understands Oracle metrics. This baseline is the foundation of every compliance position and every negotiation. Without it, the SAM tool is reconciling deployment against a guess. See our contract review service for how we construct a defensible entitlement baseline.
6. Using SAM data in a negotiation.
The right use of SAM data is internal and strategic. Before a renewal, the SAM output tells you where you are over deployed and where you have shelfware, which informs the negotiation strategy. Before an audit, the SAM output lets you find and remediate exposures privately, on your own timeline, rather than discovering them under audit pressure.
The wrong use is to hand the raw tool output to Oracle, or to run an Oracle verified tool that shares the data automatically. The negotiation principle is that you control the disclosure. You decide what to share, when, and in what form, after you have validated the interpretation. See our Oracle on AWS compliance note and the Oracle Database product page for the entitlement structures the data has to reconcile against.
7. Choosing and governing a SAM tool.
When selecting a SAM tool for an Oracle estate, the buyer side criteria are control first and features second. The tool must keep the data inside the buyer's control with no automatic transmission to Oracle. It must allow the buyer to apply its own counting interpretation rather than imposing the Oracle maximal view. It must cover database options and management packs comprehensively. And it must integrate with a clean entitlement baseline.
Governance is as important as selection. The SAM function should report internally, validate every output against the contract, and treat the tool as decision support rather than a compliance authority. This governance posture is what converts the SAM investment into a negotiating asset. See our database licensing deal page for how the data supports the commercial position.
8. What disciplined buyers do.
- Own the data. Keep SAM output inside the buyer's control with no automatic sharing to Oracle.
- Apply your own interpretation. Do not accept the Oracle maximal counting logic as fact.
- Build a clean baseline. Construct entitlements from the actual contracts, validated by someone who knows the metrics.
- Cover options and packs. Use the tool to catch inadvertent option usage early.
- Treat output as analysis. The tool starts the conversation, it does not conclude it.
- Control disclosure. Decide what to share, when, and in what validated form.
- Govern internally. The SAM function reports to the buyer, not to the vendor.
For the broader framework see our licensing compliance pillar, the virtualization compliance note, the audit defense service, and the Oracle Audit Defense Handbook.
Sitting across from Oracle and not sure your numbers are right?
Most procurement teams bring in an independent advisor before signing. OracleNegotiations.com sits on your side of the table. We run the analysis, build the counter offer, and negotiate alongside your team. Fixed fee or success fee. We only get paid when you save. Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500 plus engagements across Oracle's full product line. We work alongside them on the most complex ULA exits, audit defence cases, and renewal negotiations.