Module 5 opens, and for the first time the phone rings from their side. The audit is a scheduled revenue motion, not an accusation: GLAS measures, sales settles, and the cycle reaches every meaningful estate every three to five years. This session maps the machine: the actors from LMS to the Java enforcement motion, the triggers your own optimization creates, the one line test that separates a soft audit from a formal one, the five phase process across six to eighteen months, and the anatomy of the audit letter, read line by line until the scariest document in enterprise software looks like what it is, a template.
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 CFO's did we just raise our audit risk question answered honestly, the clause free Java email classified with the one line species test, and the $4.2M preliminary finding read as the opening position it is. It closes with one audit letter annotated in six rows, each line paired with its meaning and your first move.
The full narration of this session, section by section, for reading and reference.
Welcome back, session twenty one of forty, and module five opens. For twenty sessions the course has been on your side of the table: counting rules, contracts, negotiations, support economics. Today, for the first time, the phone rings from their side. Audits. Here's the thing to hold before any detail: every Oracle customer of meaningful size gets audited eventually. Not because they did something wrong, but because the audit is a scheduled revenue motion, a machine that runs on a cycle, and sooner or later the cycle reaches your number. That reframe changes everything about how the next five sessions feel. An audit letter is not an accusation and not a catastrophe; it's a process with named actors, known phases, and a predictable ending, and the outcome is decided almost entirely by preparation that happens before the letter arrives. Which is convenient, because preparation is what the last twenty sessions have been building, the baseline audits, the set maps, the contract files, the records. Today we learn the machine itself: who runs it, what triggers it, the two very different species of audit, the formal process phase by phase, and the anatomy of the letter, taken apart line by line. Let's open module five.
Five takeaways. One, you'll name the machine: LMS, GLAS, what each is, what the rename meant, and, critically, where sales sits in the audit motion, because the ending explains the whole process. Two, you'll read the triggers: the events on your side that reliably invite audit attention, and the folklore that doesn't. Several of the triggers are things this course has been telling you to do, and we'll resolve that tension directly. Three, you'll tell the species apart: the soft audit and the formal audit look similar in the inbox and are completely different events, with completely different obligations, and telling them apart takes one line of reading once you know which line. Four, you'll map the process: the formal audit from notice letter to settlement, five phases, six to eighteen months, each phase with a different owner on their side and a different job on yours. And five, you'll read the letter: the actual audit letter, sentence by sentence, what each part means and what each part commits you to. By the end, the scariest document in enterprise software should read to you like what it is: a template. The stakes, next.
Four numbers to frame the module. Forty five: the days of notice the standard formal audit letter gives before kickoff. It sounds like a deadline and functions like one, but hold the deeper point: the clock that decides the outcome started years earlier, on your side, with the records you either kept or didn't. Three to five: years between audits for a typical meaningful Oracle estate. This is the cycle. If nobody in the building remembers the last audit, you are not lucky, you are due. Two: the audit species, soft and formal, and mistaking one for the other, in either direction, is the classic first week error. Treating a soft audit like a subpoena hands over data nobody was entitled to; treating a formal audit like junk mail is breach. And ninety percent, roughly: the share of audits that end in a negotiated commercial settlement rather than any kind of legal dispute. Hold that one hardest. The findings report that will eventually arrive, with its terrifying number, is an opening position in a negotiation, not a bill and not a verdict. Module five is five sessions: the machine today, your rights next, then the common findings, the defense, and finally the SAM function that makes the next audit boring. The actors, next.
Who is actually auditing you? Five named parts. First, GLAS, formerly LMS. License Management Services was Oracle's audit arm for decades; around twenty nineteen it was renamed Global Licensing and Advisory Services. The word advisory joined the letterhead; the function did not change. When I say the audit function, this is who I mean. Second, the audit clause, because GLAS doesn't act on vibes; it acts on a contractual right written into your OMA or OLSA. No clause invoked, no formal audit, and that distinction carries today's whole session. Third, and this is the one to internalize, sales, the resolution desk. GLAS measures. It does not price settlements, and it does not close deals. Findings route to your account team, and the audit ends as a commercial negotiation, on the same ladder module four taught you to climb. Fourth, partner audit firms: Oracle sometimes engages outside firms to run the fieldwork. Different letterhead, same clause, same process, same rules. And fifth, the Java enforcement motion, which since the employee metric runs as its own machine at enormous volume: email campaigns keyed to download records and telemetry, mostly soft audits, at scale. The incentive structure to hold: measurement is the middle of the process, revenue is the end. Structurally, every audit is a sales campaign with a measurement phase. Now, what puts you on the list.
Audit targets are selected, not drawn from a hat, and the selection signals are events on your side that suggest license movement. Five reliable ones. Support reduction: terminations, third party moves, lapsed renewals. Yes, that is exactly what module four taught you to do, and we'll face that head on in the knowledge check. A shrinking support stream is visible from Oracle's side and reads as a customer optimizing away from the annuity. ULA expiry and certification: session fourteen's certification window is a standing audit adjacent event, because declared numbers invite verification. Infrastructure change: hardware refresh, virtualization projects, VMware estate changes, cloud migrations. Counting rules change when platforms change, and Oracle knows which platforms you're on more often than you'd think. M&A and divestiture: entities move, licenses do not follow automatically, and deal announcements are public. The audit letter that follows a merger is practically a genre. And Java: download records tied to your domain, update telemetry, and the employee metric's arithmetic have made Java the highest volume trigger of the decade by a wide margin. The framing that matters: a trigger is a signal of movement, not an accusation. Estates that fear triggers stop optimizing, which is its own quiet tax. The prepared ones optimize anyway and keep the records. Which brings us to the CFO's question. Knowledge check one.
Knowledge check one. You ran module four's program: one support set terminated cleanly, one estate moved to third party support. The CFO, reading this module's headlines, asks: did we just raise our audit risk? A, no, support decisions and audits are unrelated processes. B, yes: support reduction is a known trigger, so the program and audit preparedness travel together, and the program was still the right call. C, yes, which is why support should never be reduced. Or D, no, only ULA customers get audited. Pause here. What does a trigger actually mean, and what does it change?
The answer is B, and the honesty in it matters, because the comfortable answers are wrong in both directions. Yes, the CFO's instinct is correct: support reduction is one of the most reliable audit triggers there is. From Oracle's side, a shrinking support stream signals exactly what it was, a customer optimizing away from the annuity. So the program raised the audit probability. Here's what it did not do: create exposure. Module four's program was built on a baseline audit, set boundary maps, and policy compliant terminations, every move documented, every notice within its window. That estate can survive the verification it just invited, and an audit that finds a clean estate is an expensive afternoon, not a crisis. This is the posture the whole module rests on: triggers are not reasons to avoid optimizing, they are reasons to optimize with records. C is the expensive misreading, protection money paid to the audit machine by never touching a bill that compounds forever. A is naive; the processes are connected by design, support data feeds target selection. D is folklore, ULA certification is one trigger among many. Write the rule down: every move that saves support money checks two boxes, the business case and the audit file. Module four taught the first box. This module is the second. Now, the two species.
Soft audit versus formal audit, the distinction everything else hangs on. Two different events wearing similar language. The soft audit: an email or a call, a license review, a Java deployment questionnaire, an invitation to discuss your usage. Friendly tone, often urgent phrasing, and, here's the tell, no contract clause invoked. No clause means no formal obligation created. The formal audit: a letter that invokes the audit clause of a named, dated agreement, from GLAS or a partner firm, with a notice period, usually forty five days, and a defined scope. The one line test, and it really is one line: does the communication cite the audit clause of a specific contract? Yes: formal, and your contract's cooperation duty applies, on your contract's terms. No: soft, and your cooperation is discretionary. Why the difference matters so much: in a formal audit, refusing to participate is breach. In a soft audit, there is no contractual deadline, no obligation to run scripts, no duty to self report, and data you volunteer creates the record they didn't have. And the escalation path, because there is one: soft audits ignored rudely, or answered with a panicked data dump, both invite the formal letter. The right soft audit response is deliberate, and it's session twenty two's subject. First, the test, tested. Knowledge check two.
Knowledge check two. An email arrives from Oracle License Management, asking you to run collection scripts and return Java deployment data within two weeks. No contract clause is cited anywhere in it. What is this? A, a formal audit, two weeks to comply or you're in breach. B, a soft audit: no contractual obligation has been invoked, so the response is deliberate and managed, not reflexive compliance. C, spam, ignore it permanently, there's no risk. Or D, a trap best answered by running the scripts immediately to show good faith. Pause here. Apply the one line test.
The answer is B. Apply the test: no audit clause cited, no named agreement, therefore no formal audit and no contractual deadline, whatever urgency the phrase two weeks is designed to manufacture. That kills A immediately. It also kills D, and D deserves a moment because it feels so responsible. Running collection scripts on request, when nothing obligates you to, hands Oracle a complete deployment record you were never required to produce, on their schedule, with no scoping, no review, and no context attached. Good faith does not require self measurement on demand, and the data dump you volunteer today becomes the baseline you negotiate against next year. C fails in the opposite direction: permanent silence reads as evasion, and unanswered Java outreach is precisely the pipeline that feeds the formal audit machine. The email is real, the sender is real, and it deserves a real, managed response. B is the discipline: acknowledge professionally, route it to the single point of contact, and decide deliberately, which sometimes means limited engagement, sometimes a polite decline, always a decision rather than a reflex. Exactly what you can decline, what you must provide once a clause is invoked, and how to keep a soft audit from escalating: that is session twenty two, in full. Today's job was recognition, and you just passed. The formal process, next.
The formal audit, five phases, six to eighteen months end to end. Phase one, notice: the letter arrives, invoking the clause, naming scope, proposing kickoff. The forty five day clock is theirs; your preparation clock, as we said, started years earlier. Phase two, kickoff and scoping: entities, programs, environments, and timeline get agreed in the opening meetings. Underline this phase: scope control here shapes everything downstream, which entities are measured, which programs, which environments, and scope is negotiated, not dictated, within what your clause actually grants. Session twenty two again. Phase three, data collection: Oracle's measurement scripts and deployment worksheets run in your environment, on a schedule you negotiate, and, a point many estates never learn, with output you can review before it leaves the building. Phase four, analysis and findings: GLAS turns the raw output into a findings report, priced at list, built on the most conservative reading of every ambiguity, matching service levels style. Preliminary findings first, which invite challenge, then final. And phase five, resolution: the file moves from GLAS to sales, and the audit becomes what it was always going to become, a negotiation, compliance claims traded against purchases, subscriptions, and commitments. Session twenty four owns that phase. Hold the shape: measurement in the middle, commerce at the end. The report that reads like a verdict is one side's maximal draft of a deal that hasn't been negotiated yet. Now, the letter itself.
The audit letter, anatomy in five parts, because the formal letter is a template, and reading it as a template removes most of its menace. Part one, the sender: GLAS, or a partner firm acting for Oracle. The signature block and reply address tell you which, and both mean the same clause is in play. Part two, the clause citation, the sentence that makes it formal: pursuant to the audit provision of your agreement, with the agreement named and dated. Find that sentence first, every time; it tells you which rulebook governs everything that follows. Part three, the scope statement: which programs and which legal entities. Read it precisely, because what is not named is not in scope, and scope creep during an audit is negotiated, not automatic. If the letter names Database and WebLogic, a request for your Java deployment data is a new conversation, not a continuation. Part four, the ask and the clock: cooperation, a kickoff meeting, measurement tools to be run, and the notice period, usually forty five days, which runs to first response, not to completion. And part five, what the letter does not say, which is the part panic invents: no accusation, no finding, no amount. The letter's arrival is not evidence of noncompliance. It is the machine reaching your number in the cycle. File every date and every named entity on day one. What the prepared estate does with week one, next.
The first week, five moves, all boring, all decisive. One voice: a single point of contact for all audit correspondence, named on day one, and everyone else, every DBA, every admin, every helpful soul on a support call, instructed to forward, not answer. More audit damage is done by well meaning side channel answers than by any script output. The team, assembled: SAM or licensing lead, legal, procurement, and an executive sponsor. Small, named, briefed before kickoff, so the audit meets an organization, not a scramble. The contracts, pulled: the cited agreement and its audit clause, plus every order placed under it. The clause is the rulebook for scope, notice, confidentiality, and cost allocation, and you cannot play a game whose rules you haven't read. Nothing hidden, and I'll say this one carefully: no deployment changes designed to disguise history. Honest cleanup of go forward usage, uninstalling things you never used, is legitimate housekeeping. Rewriting the past, deleting evidence, backdating records, is how defensible positions die and how commercial disputes become something worse. The audit tests your records; let it. And fifth, your own count, started: the internal measurement begins in parallel, on your tools, against the baseline audit you already keep from module four's homework, so that when their findings arrive, they land on a desk that already knows the real answer. Which sets up the final check: the findings arrive. Knowledge check three.
Knowledge check three. Months into the formal audit, the preliminary findings report arrives: four point two million dollars in alleged exposure, priced at list. What is this document? A, a bill: budget for it and pay it. B, an opening position: maximal readings of every ambiguity, priced at list, headed for a commercial negotiation. C, the start of inevitable litigation. Or D, a document that's safest to ignore. Pause here. Who receives this file next, and what do they do with files?
The answer is B, and the reasoning is the session's whole shape, applied. Follow the file. GLAS does not collect money. It measures, writes findings, and hands the file to sales, and sales does with files the only thing sales ever does with files: negotiates them. So read the four point two million the way it was constructed. Every ambiguity resolved against you. Every metric at list price, no discount you've ever earned applied. Challengeable findings, the VMware interpretation, the disaster recovery counting, the options that were enabled but never used, all included at full weight. No netting against anything you actually need to buy. That is not fraud; it is an opening position, authored by the party that got to draft first, and module four taught you exactly what opening positions are for. The vast majority of audits resolve commercially: claims reduced by challenge, sometimes dramatically, and the remainder converted into purchases or subscriptions the estate often needed anyway. Which is why A is the most expensive response available, paying the first draft of a negotiation. C mistakes the rare exception for the norm; litigation is uncommon precisely because both sides prefer the deal. And D, once a clause has been invoked, is the one genuinely dangerous square on the board. Sessions twenty three and twenty four teach the two halves of shrinking that number: challenging the findings, then negotiating the remainder. The letter, annotated, next.
One audit letter, read line by line, the session applied in six rows. From: Oracle GLAS. The audit function, clause in hand; this is formal. First move: log it, date it, route it to the single contact, today. Pursuant to your OMA dated twenty twenty one: the rulebook is that specific contract's audit clause. Pull that agreement and every order under it before the week ends. Scope: Database and WebLogic, all affiliates. Named programs and named entities only; nothing else is in scope yet, and your move is to map which entities actually hold those licenses, because all affiliates will be worth a scoping conversation. Within forty five days, a kickoff meeting: that's the clock to first response, not to completion. Calendar it, and have the team assembled well inside it. You will run Oracle's measurement tools: collection is coming, and output is reviewable before submission, so your parallel count starts today, not when their scripts do. And the closing line, we anticipate a collaborative process: read it honestly, because it's true. The resolution will be commercial, as it almost always is, which means the negotiation started when this letter arrived, and every professional, composed, well documented response from here forward is a negotiating position. Nothing in the letter is an accusation. Nothing in it is optional. Both facts at once: that is the posture. Recap, next.
Session twenty one in three sentences. One, audits are a scheduled revenue motion, run by GLAS on a three to five year cycle, triggered by the visible signals of your own optimization, support moves, certifications, platform changes, Java, which is a reason to optimize with records and never a reason to stop optimizing. Two, the species test is one line, does the communication invoke the audit clause of a named agreement, and everything about your obligations follows from that answer: contractual cooperation on the contract's terms if yes, deliberate discretionary response if no. Three, the formal process is measurement in the middle and commerce at the end, five phases from letter to settlement, and the findings report with the terrifying number is an opening position headed for a negotiation, not a verdict headed for a courtroom. That composure, the letter is a template, the finding is a draft, the ending is a deal, is what this module installs, and it rests entirely on preparation that happens before the letter arrives. Next session: the rulebook itself. What the audit clause actually obligates, what Oracle's rights genuinely are, what yours are, scope control in practice, and what you can lawfully decline, including in the soft audit inbox. The session that turns composure into specific sentences. Homework first.
Homework, about an hour, and this week it builds your audit file. One, find your audit clauses, plural: every Oracle agreement in force, locate the audit provision in each, note the notice period and the cooperation language. They differ between agreement generations, and the differences matter next session. Two, name the single voice: decide, today, who receives all audit correspondence, and write the one paragraph instruction that tells everyone else to forward and not answer. Send it before you need it. Three, score your triggers: the last twenty four months of your estate against today's list, support moves, certifications, infrastructure change, M&A, Java downloads. Your audit probability, assessed honestly, on one page. Four, find the last audit: when it was, what scope, how it resolved, and where the file went. Institutional memory is defense material, and in most estates it retired with whoever handled it. And five, open the audit file: one folder, the contracts, the clauses, the contact plan, the trigger score, and module four's baseline audit. Session twenty five turns this folder into an operating model; today it just needs to exist. That's the hour. See you in session twenty two, where we read the rulebook.
Five reads, all free on redress compliance dot com. First, the Oracle audit letter, what to do when you receive one: today's letter anatomy at checklist depth, the piece to have bookmarked before you need it. Second, how Oracle selects audit targets: the trigger list worked from the selection side, an advisory written for CIOs and procurement leaders. Third, Oracle GLAS versus LMS, what changed: the rename, the Java enforcement motion, and what stayed exactly the same underneath the new letterhead. Fourth, the audit letter first forty eight hours checklist: the first week posture from today's session, compressed to hour by hour moves. And fifth, Oracle audit triggers, what invites LMS: the full trigger catalog with the mitigations for each. That's session twenty one. Module five is open, the machine has a map, and the letter on the desk is a template with a clause citation, a scope statement, and a clock, headed, like almost every audit before it, toward a negotiation. Next session we read the rulebook it runs on: your rights, their rights, and the difference. See you there.