The audit findings report writes itself, assembled from five standard claim families: VMware and the policy paper that no contract incorporates, options and packs flagged by usage data that overcounts by design, disaster recovery estates where noise and genuine exposure share a report line, named user arithmetic inflated by departed accounts, and Java priced on the employee metric. This session teaches each claim, its honest core, and its written challenge, then grades session 21's $4.2M preliminary finding line by line until $2.4M collapses on evidence, $600K on its own data, and $1.2M walks forward as the settlement baseline.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
A taught session with three knowledge checks: the $2.1M whole vCenter VMware claim collapsed to the contained cluster on contract language, the three year old Tuning Pack upgrade artifact withdrawn on its own usage history, and the graded report answered with challenges, struck noise, and a held baseline. It closes with the $4.2M preliminary finding dissected line by line into the $1.2M that actually enters settlement.
The full narration of this session, section by section, for reading and reference.
Welcome back, session twenty three of forty. Two sessions ago the audit letter arrived, and last session you learned the rulebook it runs on. Today, the material itself: the findings. Here's the open secret this session is built on: the Oracle audit findings report writes itself, because it's assembled from a short, stable menu of standard claims. VMware and virtualization counting. Options and management packs flagged by usage statistics. Disaster recovery estates. Named user shortfalls. And, in recent years, Java. Five families, and together they cover the large majority of the exposure in nearly every audit report ever delivered. That stability is your advantage. If you know the menu before the report arrives, you can grade your own estate in advance, build the evidence before it's needed, and read the eventual findings the way an analyst reads them: some lines challengeable on contract language, some challengeable on evidence, some genuinely owed, and some just noise. By the end of today you'll be able to do exactly that grading, and we'll do it live, because session twenty one's four point two million dollar preliminary finding comes back today, and we're going to take it apart line by line. Let's meet the five.
Five takeaways. One, you'll predict the report: the five finding families that fill nearly every Oracle audit, known before the fieldwork even starts, which changes the audit from an ambush into an exam you've seen the questions for. Two, you'll argue VMware: the counting dispute that produces the biggest number in most reports, and the difference between what the policy paper says and what the contract you actually signed says. Three, you'll kill false positives: the options and packs claims built on usage flags that overcount by design, and the evidence test that separates an artifact from adoption. Four, you'll sort the disaster recovery claims: three standby postures, three completely different answers, some noise, some genuinely owed. And five, you'll grade every claim: the discipline that sorts a findings report into challengeable, negotiable, and noise, before anyone responds to anything. One warning before we start, and it's the honest thread through the whole session: not every finding is inflated. Real exposure exists, and pretending otherwise wastes the credibility your real challenges need. The defense is grading, not denial. The stakes, next.
Four numbers. Five: the finding families, VMware, options and packs, disaster recovery, named user counts, and Java, that cover the large majority of audit exposure everywhere. Learn five patterns and you've learned the report. Fifty percent, often more: the share of a typical findings report that's challengeable on contract language or usage evidence. Half the terrifying number is negotiating position, which is exactly why session twenty one taught you the finding is an opening position, not a bill. Zero: the number of contract clauses that mention VMware, vMotion, or the partitioning policy. Hold that one, because the largest finding in most reports rests on the thinnest paper, and the whole VMware section turns on it. And twenty five: the Named User Plus minimum per processor on Database Enterprise Edition, the arithmetic behind most user count claims, straight from session two. And one thread to watch: session twenty one's four point two million dollar preliminary finding is back today. We've carried it through the letter and the rulebook; today it gets dissected, family by family, and what walks out of this session is the real number that session twenty four will settle. The biggest number first: VMware.
Finding one, VMware, the biggest number in the report. The claim: your Oracle databases run on a vSphere cluster, soft partitioning does not limit licensing, therefore every host in the cluster needs licenses, and in the wider readings, every host under the vCenter, because vMotion could move the VM anywhere. Could run, counted as running. Where does that rule come from? Not your contract. It comes from the partitioning policy, a document on Oracle's website, explicitly marked for educational purposes only, which no OMA incorporates by reference. You never signed it. What did you sign? A Processor definition that counts processors where the programs are installed and or running. Installed and running are facts, and facts have evidence: host affinity rules, dedicated cluster configurations, DRS boundaries, vMotion history logs showing where the software actually lived. That's the defense, in two moves: contract over policy, and containment evidence over possibility. Now the honest caution, because this defense has a precondition: it works for estates that actually bounded their Oracle hosts. Uncontained sprawl, Oracle VMs drifting across a general purpose farm, is real exposure under any reading of any document, which is why session four taught containment years before any audit needed it. The claim is priced on the policy; it is defended on the contract. Let's test that immediately. Knowledge check one.
Knowledge check one. The findings claim two point one million dollars for all twenty four hosts under your vCenter, because vMotion could move the Oracle VMs anywhere. In fact, the databases run on a four host dedicated cluster with affinity rules. Your response? A, pay it, the partitioning policy says soft partitioning does not count. B, challenge it: the contract licenses installed and or running, and your containment evidence shows exactly where that was. C, delete the vMotion logs so nothing can be proven either way. Or D, argue that virtualized Oracle needs no licenses at all. Pause here. Which document is the claim priced on, and which one did you sign?
The answer is B, and the reasoning is two questions asked in the right order. First: which document prices the claim? The partitioning policy, an educational paper referenced by no clause you ever signed. Second: which document governs? Your OMA, whose Processor definition counts where the programs are installed and or running. The gap between those answers is the entire challenge. The claim prices a possibility, everywhere the VM could go. The contract licenses a fact, everywhere the software actually was. And facts have evidence: your four host cluster, the affinity rules, the DRS boundaries, the vMotion history. That evidence, presented in writing, routinely collapses whole estate claims down to the contained cluster, twenty four hosts to four, and that difference is most of the two point one million. A pays a policy paper as though it were a contract term, which is the single most expensive reflex in the history of Oracle audits, repeated annually by estates that never read their own Processor definition. C, and let's be completely clear about this one: deleting logs converts a strong commercial position into misconduct. Evidence destruction ends every defensible argument you had and creates a category of problem no negotiation can fix. Session twenty one said it and it bears repeating: the audit tests your records, let it. D overcorrects into folklore; virtualized Oracle absolutely requires licenses for the capacity where it's installed and running, which is precisely what your evidence shows you already licensed. Four hosts, not twenty four. Finding two: the false positive factory.
Finding two, options and packs, the false positive factory. The claim: feature usage statistics show Diagnostics Pack, Tuning Pack, Partitioning, or Advanced Security in use on databases that were licensed without them, priced per processor, and on an estate of any size it adds up fast. Here's why the raw data overcounts by design. The options install with the database whether you licensed them or not; there is no unlicensed edition of the binaries. Upgrade scripts touch features in passing. Default configurations sample diagnostic data automatically. The usage view records all of it identically: a flag is set whether a DBA adopted the feature into daily workflow or a system process brushed past it once during a maintenance window. A flag is not a purchase decision. So the evidence test, four questions: when was the feature last used, by whom, how often, and in what workflow? One touch by a system account, years ago, never repeated: artifact. Sustained invocation by named DBAs in an operational routine: adoption. The defense follows the test: usage history analysis separating artifacts from adoption, configuration changes turning the unlicensed features properly off, and the inadvertent enablement argument for the isolated touches. And the honest caution, as always: real sustained use of an unlicensed option is a genuine finding. The defense sorts artifacts from adoption; it does not make adoption free. This family is exactly why session twenty two insisted on reviewing script output before submission: the challenge starts in your own review pass. Testing it. Knowledge check two.
Knowledge check two. The findings include six hundred thousand dollars for Tuning Pack on eight databases. The usage statistics show exactly one detected use per database, each timestamped the night of a version upgrade, three years ago, never since. What is this? A, a genuine finding, any detected use means the license was required. B, a challengeable artifact: one system generated touch during an upgrade is not adoption, and the usage history proves it. C, grounds to accuse the auditors of fabricating data. Or D, something to concede quickly, to buy goodwill for the bigger VMware discussion. Pause here. What does the usage history actually show, and who touched the feature?
The answer is B, and the way to see it is to read the evidence like an analyst reads anything: for pattern. One detected use per database. Timestamps identical to the upgrade windows. Zero recurrence in three years. No DBA workflow anywhere that invokes the pack. That pattern has a name, the upgrade script artifact, and it's among the best documented false positive families in Oracle's own collection data: system processes touching features during maintenance, recorded identically to human adoption. The challenge writes itself, and per session twenty two, it is written, never argued verbally: the usage history, the timestamp correlation, the absence of recurrence, the configuration evidence that the pack's interfaces were never enabled for actual use, submitted as a documented rebuttal. Findings with this evidence profile get withdrawn routinely, because the auditors' own data is what proves the challenge. Now the wrong answers, and two of them teach something. A states a rule that exists in no contract: licenses attach to use, and the entire question is whether use in any meaningful sense occurred. A three year old system touch is not it. C mistakes overcounting for fabrication; the data is real, the interpretation is wrong, and hostility toward the fieldwork team spends credibility your VMware challenge is going to need. And D, the subtle one: conceding artifact findings to appear cooperative teaches the room that your challenges are postures rather than evidence, which quietly weakens every real challenge in your file. Concessions are currency, and session twenty four's settlement is where currency gets spent, deliberately. The rule for the whole family: artifacts get rebutted with evidence, adoption gets negotiated with leverage, and telling them apart is what your review pass is for. Finding three: the standby estate.
Finding three, disaster recovery, and this is the mixed family, where honest exposure and inflated claims share a report line, so the sorting matters more than anywhere else. Three postures, three answers. Posture one, backup: copies of the software and data at rest, on tape, on disk, in a vault. No license required for a copy at rest, and the narrow allowances cover restoring to test your backups. Claims that price your backup sets as deployments are noise, and they do appear. Posture two, the failover allowance: a genuinely cold node in a failover cluster, sharing storage with the primary, may run unlicensed for up to ten separate days per year, the ten day rule. A node that exceeds those days, or that runs warm, needs licenses. The evidence is your failover log, which is why you keep one. Posture three, active standby, and here the claim is usually genuine: Data Guard, mirroring, replication of any flavor where the standby database is installed and running. Running is running. The standby needs full licenses, same metric, same options as primary. No contract reading rescues an unlicensed active standby. The common inflations to watch: cold sites priced as active, failover days assumed exceeded with no log evidence either way, test restores priced as standing deployments. Each has an evidence answer: topology documentation, the failover record, the restore log. Grade each line separately: some DR lines are noise, and some are the most solid claims in the entire report. Finding four: the arithmetic claim.
Finding four, named user shortfalls, the arithmetic claim, and arithmetic can be checked. The claim comes in two shapes: more users with access than licenses held, or fewer licenses than the contractual minimums, twenty five Named User Plus per processor on Enterprise Edition, whichever is greater, exactly as session two taught. The rule that powers most of these claims is multiplexing: users reaching the database through middleware, an application server, a batch interface, still count at the front end of the chain. The integration with one service account and four thousand real humans behind it counts four thousand, not one. That rule is contractual and real. Where the claims inflate is the counting: departed employees whose accounts were never deprovisioned, service and system accounts counted as humans, and the assumption that every employee in the company uses a system that twelve people actually touch. Each inflation has the same answer: a real user inventory. Current access lists, deprovisioning records tied to HR dates, and the actual front end population reaching each database. Count it yourself, before accepting their count, because the party with the better user inventory wins the arithmetic argument more or less automatically. And the honest caution for this family: genuine growth past the license count is a real finding, the minimums are contractual, and NUP claims are more often negotiable than challengeable. The estates that kept the inventory current argue from records. Everyone else argues from memory, and memory loses. Finding five: the newest line.
Finding five, Java, the newest line in the report and the one with the most alarming arithmetic. The claim: Oracle JDK deployments, found by scripts or inferred from download logs, priced on the employee metric, meaning every employee in the company, times the per employee subscription price, times, in the aggressive versions, the years since the use began. Back support on a headcount metric produces startling numbers from small facts, which is precisely the design. The evidence base deserves scrutiny: download logs tied to your domain and update pings are real data, but the leap from one developer's download to estate wide commercial use is an inference, not a finding. First response, before any of that: the scope question. Java frequently is not among the audit letter's named programs, and Java SE terms often live outside the OMA entirely, in click through and download licenses with their own audit language. Check the scope minute before engaging on Java at all; a Java claim inside a database audit is very often a new conversation wearing the old audit's letterhead, session twenty two's fence again. The substantive defense is an actual Java inventory: which JDKs, which versions, and which license terms each falls under, no fee terms, OTN terms, legacy perpetual licenses, and where OpenJDK replaces the Oracle JDK cleanly, that migration priced. And the honest caution: widespread commercial use of licensable Oracle JDK versions is real exposure at painful arithmetic. The defense is an inventory, not a denial. Session thirty five gives Java its full hour. Now, the discipline that assembles all five.
The challenge discipline, five steps in strict order, because the order is what makes it work. Step one, scope check first: before any technical argument, strike everything outside the noticed programs, entities, and environments. Session twenty two's scope map does this in an afternoon, and it's the cheapest reduction in the whole process: claims that simply do not belong in this audit. Step two, sort into three piles: challengeable, on contract language or usage evidence. Negotiable, because genuinely owed. Noise, wrong on their own data. Every line gets exactly one label, and the grading meeting where your team argues about labels is the most valuable meeting of the whole audit. Step three, rebut in writing: every challenge travels with its evidence attached, the contract language, the usage history, the topology records, the user inventory. No verbal challenges, ever; verbal challenges are conversations, written challenges are positions. Step four, price the remainder: the genuine pile, repriced at your actual discount reality rather than list, because list price findings are an anchor, not a fact. That repriced number is the true baseline entering session twenty four. And step five, concede nothing by reflex: every concession is currency in the settlement, and currency spent early, to seem agreeable, purchases nothing that survives the meeting. Cooperative in process, firm on substance, everything in writing. Now let's run the whole discipline against the number we've been carrying since session twenty one. Knowledge check three.
Knowledge check three. After grading, your four point two million dollar report sorts into two point four million challengeable, one point two million genuine, and six hundred thousand noise. The auditors propose a single response conversation. What goes in your written reply? A, agreement to the four point two million, with a request for a payment plan. B, the challenges with evidence attached, the noise struck with reasons, and no admission yet on the genuine pile, because it's the settlement baseline. C, only the noise objections, conceding the rest to seem reasonable. Or D, a refusal to respond to any finding. Pause here. Which pile is leverage, which is currency, and which is just wrong?
The answer is B, and the logic is that each pile has a different job, and only B gives every pile its job. The challengeable two point four million is leverage: rebutted in writing with evidence, the containment records, the artifact analysis, the topology documents, it shrinks the baseline before the commercial conversation ever starts, and the preliminary findings phase exists precisely to receive those rebuttals. The six hundred thousand of noise gets struck briefly, with reasons and without heat, because unanswered noise rides into the settlement as padding. And the genuine one point two million gets, for now, exactly nothing: no admission, no payment offer, no visible anxiety. Acknowledged early, it becomes a floor under the negotiation. Held to the settlement, it becomes raw material, the thing that session twenty four converts into subscriptions, purchases, and commitments the estate partly needed anyway, at a fraction of the claimed number. A pays the first draft, which session twenty one already named the most expensive response available. C runs the logic backwards, conceding the large piles to argue the small one, maximum payment for minimum savings, and it tells the room your grading can't be trusted. D breaches the cooperation duty for nothing; a response is owed, and the strong response exists. And notice, before we dissect the whole thing, what made B possible: none of it was improvised in the meeting. The containment evidence was built in session four. The output review habit came from session twenty two. The scope minute was written at kickoff. The findings report tested the estate's paperwork, and the paperwork held. The full dissection, next.
The four point two million dollar preliminary finding, graded line by line, the whole session in one table. The VMware claim, two point one million for all twenty four hosts under the vCenter: challenged on the contract, installed and or running, with the affinity rules and vMotion history holding the software to its four host cluster. Reduced to three hundred fifty thousand, the licenses genuinely short on the real cluster. The Tuning Pack claim, six hundred thousand across eight databases: challenged on the usage history, one upgrade night artifact per database, three years old, never repeated. Withdrawn entirely. The Data Guard standby, seven hundred thousand: genuine. The standby was installed and running, and no reading rescues it. Moved to the negotiable pile, repriced at the estate's discount reality instead of list. The named user shortfall, three hundred thousand across two systems: mixed. Forty percent of the claimed users turned out departed or service accounts, struck on the inventory; roughly one hundred eighty thousand of genuine growth remains, negotiable. And the Java line, five hundred thousand priced on every employee: scoped out. Java was never a noticed program, and it's parked for separate handling, with its own inventory built first, on your timeline. The baseline entering settlement: roughly one point two million genuine at list, against a four point two million opening. Nothing here was clever. It was records: containment built in advance, output reviewed before submission, scope minuted at kickoff, every challenge in writing. Recap, next.
Session twenty three in three sentences. One, audit findings reports assemble from five standard families, VMware counting, options and packs, disaster recovery, named user arithmetic, and Java, and knowing the menu in advance converts the audit from an ambush into an exam you've already seen. Two, every line gets graded into exactly one of three piles, challengeable on contract or evidence, negotiable because genuine, or noise, and challenges travel in writing with their evidence attached, because written positions survive meetings and verbal objections do not. Three, the genuine remainder is not a bill; it is the settlement baseline, held without admission and repriced away from list, until the negotiation converts it into a commercial outcome, which is exactly where the course goes next. Session twenty four is the one this module has been building toward: audit defense and settlement. The response strategy end to end, the settlement meeting itself, who attends, what's said, what's traded, and the conversion of a compliance claim into a negotiated deal, using every piece of leverage module four taught you and every record module five made you keep. The one point two million meets the renewal calendar. Homework first.
Homework, about an hour, and this week you audit yourself before anyone else does. One, run the five findings against your own estate: VMware containment, options flags, DR topology, user counts, Java inventory, graded honestly into the three piles. What would an auditor claim, and what would survive your own challenge process? That one page is the most valuable risk document your estate can own. Two, check the containment: where does Oracle actually run in your virtual estate, and what evidence proves the boundary, affinity rules, cluster configs, vMotion history? If the answer is no evidence exists, session four's homework just became urgent. Three, pull the feature stats: one production database's feature usage view, read with the artifact test, when, who, how often, what workflow. Practice the grading on real data. Four, map the DR posture: every standby environment labeled backup, failover, or active. The active ones either have licenses or belong on the risk register today, at real prices, before an auditor prices them at list. And five, refresh one user count: your largest NUP system, current access list against licenses held, departed accounts flagged against HR dates. Twenty minutes, and you'll have the real number before anyone else claims theirs. That's the hour. See you in session twenty four, the settlement.
Five reads, all free on redress compliance dot com. First, Oracle on VMware, the licensing guide: the counting dispute in full, the policy paper's history, and the containment defense worked in depth. Second, Oracle Database Enterprise Edition options, pricing and audit exposure: the options and packs family, priced per processor, with the false positive catalog. Third, Oracle disaster recovery licensing: backup, failover, and standby, and exactly which topologies need licenses, today's three postures in full detail. Fourth, challenging Oracle audit findings: the written rebuttal process, evidence standards, and what withdrawal actually takes. And fifth, Oracle Java audit defence: the employee metric claim, the download log evidence, and the inventory that answers both. That's session twenty three. Five families, three piles, everything in writing, and a four point two million dollar report entering the settlement at one point two, because the records held. Next session the module peaks: the settlement itself, where the graded remainder meets the negotiation ladder, the fiscal calendar, and a renewal Oracle wants, and a compliance claim becomes a commercial deal. Bring the file. See you there.