This is the operational playbook for the first thirty days of an Oracle audit: who replies, what the acknowledgement says, which documents you find before anything else, and how to negotiate a written audit protocol before a single collection script runs.
Key takeaways
- Acknowledge in writing within five business days, from one named person, confirming receipt and process and absolutely nothing else.
- One channel, one voice. Every reply to Oracle leaves from the same mailbox, and no engineer, manager, or executive corresponds directly.
- Find the prior audit closure letter before you find anything else. A release through a stated date puts everything before it beyond reach.
- The audit protocol is a negotiated document covering ten things, and it is signed before any script executes. Nothing in the clause obliges you to skip it.
- Data handling belongs in the protocol. Collection output can contain named user accounts and host names, and offshore transfer is a legal question, not an IT one.
- Java runs as a separate track with a separate metric, a separate data source, and often a separate Oracle team. Do not let it ride inside a database audit.
- The most expensive document in an audit is usually an internal email. Establish privilege before anyone writes down a compliance opinion.
An Oracle audit notice is a few paragraphs. What follows can occupy a licensing team for nine months and a finance team for five years.
Almost none of that is decided by how well you argue at the end. It is decided by what you agreed to, in writing, before anyone ran anything.
Who replies to the Oracle audit letter, and what do they say?
One named person replies, in writing, within five business days, confirming receipt and the intended process and committing to nothing else. That is the entire first reply.
The temptation is to answer helpfully. Helpfulness in the first reply is how buyers concede scope, timing, and method before they have read their own contract.
What the acknowledgement should contain
- Confirmation of receipt and the date received.
- The name, title, and contact details of your single point of contact for the matter.
- A request that all correspondence be directed to that person and no one else.
- A request for the specific contractual provision Oracle is relying on, and the agreement it sits in.
- A request for the proposed scope in writing: entities, programs, time period, and environments.
- A statement that you will respond substantively once scope and protocol are agreed.
What it must not contain
- Any admission, estimate, or characterization of your compliance position.
- Any agreement to a kickoff date, a data deadline, or a collection method.
- Any list of environments, hosts, entities, or products that Oracle did not already name.
- Any statement about future architecture plans, migrations, or renewals.
- Any apology, and any explanation of why something might be the way it is.
Do not circulate the letter widely. Every additional recipient is another person who may reply, speculate in writing, or forward it to a vendor contact.
Oracle publishes its contract families on its contracts page, and the function that sent the letter is described on its license management services page. Read both before you reply, and read your executed agreement first of all.
Who should be on the response team, and who must stay off it?
Six roles, one voice. The team is deliberately small, because the risk in month one is not slowness, it is uncontrolled contact.
The audit response team, and who is allowed to speak
| Role | Owns | Speaks to Oracle? | First deliverable |
|---|---|---|---|
| Executive sponsor | Decisions and budget | Only at the close | A written mandate for the single point of contact |
| Single point of contact | All correspondence | Yes, exclusively | The acknowledgement letter |
| Counsel | Clause reading and privilege | On request only | A privilege instruction to the whole team |
| Licensing and SAM lead | Entitlement and counting | No | The entitlement register from contracts, not spreadsheets |
| Infrastructure and database leads | Estate facts and collection | No | A host inventory with owner and environment class |
| Independent advisor | Method and precedent | Through the contact | A first pass exposure range for the sponsor |
The five communication rules
- Every outbound message to Oracle leaves from one mailbox, in writing, and is copied to counsel.
- Nobody outside the team speaks to Oracle about the audit, including the account team on unrelated business.
- No screen sharing, no live console walkthroughs, and no ad hoc calls without an agenda and a note taker.
- Every Oracle call gets a written summary sent back the same day, so the record is yours.
- Anything material goes to counsel before it goes to Oracle. That includes what looks like a routine data question.
Privilege, and the most expensive email in the audit
The single most damaging document in most audits is an internal one, written in week two by someone trying to be helpful, saying that a team thinks it may not be licensed for something.
Establish privilege before anyone assesses anything. Counsel instructs the team, the internal assessment is produced at counsel's direction, and compliance opinions live in that channel rather than in a shared drive.
This is not about hiding facts. Facts about your estate are discoverable and should be accurate. It is about not converting a preliminary guess into a written admission.
Which documents do you need before you answer anything?
Seven document classes, and one of them is worth more than the other six combined. Find them before you agree a scope, because scope arguments are won with paper.
The seven you actually need
- The executed master agreement. The signed original, with every amendment. Not a template, not a copy from the intranet.
- Every ordering document. The quantities, metrics, territories, and any special terms you negotiated at the time of purchase.
- Prior audit closure letters. A release through a stated date makes everything before that date unavailable to the current review.
- Support renewal quotes and identifiers. Your support renewal history is a better entitlement record than any internal spreadsheet, because Oracle produced it.
- ULA agreements and certification letters. What was certified, when, and on what basis.
- Acquisition and divestiture agreements. Specifically the clauses that assigned, or failed to assign, Oracle licenses.
- Corporate structure records. Which legal entities exist, which signed what, and which were acquired after signature.
Why the closure letter matters so much
If a previous Oracle audit closed with a written release, the estate as it stood at that date has already been resolved. A new review starts from that line, not from the beginning of time.
In our engagements this document is missing from the buyer's files far more often than it should be. Ask procurement, ask legal, ask the person who has since retired, and ask Oracle for a copy in writing.
Reading entitlement from support records
Your entitlement is what the ordering documents say, and support renewals are the running proof of it. Oracle's technical support policies govern how those sets behave, including matching service levels and repricing when part of a set is terminated.
Reconcile every support identifier against every ordering document. Gaps in either direction are worth knowing about before Oracle finds them, and surplus entitlement is as common as shortfall.
What should the audit protocol say before any script runs?
Ten things, in writing, signed by both sides. The protocol is the highest value document in the entire audit and the clause does nothing to prevent you asking for it.
Scope is negotiated before collection because nothing about collection is reversible. Data released under a vague scope cannot be recalled, and it becomes the baseline for arguments you have not had yet.
The ten clauses of a written audit protocol
| Clause | What to specify | What it prevents |
|---|---|---|
| Entities | Named legal entities, by registration number | Silent expansion into subsidiaries that never signed |
| Programs | Named product families and versions | A database audit that quietly becomes a middleware audit |
| Period | Start and end dates, anchored to any prior closure | Findings reaching back past a released date |
| Environments | Production, standby, failover, test, development, training | Non production estate counted as if it were production |
| Method | Which scripts, which versions, which hosts | Unbounded collection across the whole estate |
| Execution and review | You run them, you review output before release | Raw output leaving before anyone has read it |
| Data handling | Storage, access, transfer, retention, deletion | Personal data and host names crossing borders unnoticed |
| Communication | One channel, written record, agreed cadence | Side conversations with engineers and executives |
| Milestones | Dates, and a right to review draft findings | A finished number circulating inside Oracle first |
| Closure | What ends the audit, and in what document | An audit that never formally finishes |
Environments are a scoping decision, not a technicality
Oracle treats production, standby, failover, test, development, and training estates differently, and the rules live in the program documentation and the Oracle software investment guide rather than in the audit clause.
Enumerate every environment class in the protocol and state how each will be treated. A test estate swept in without discussion is one of the most common avoidable findings we see.
The counting rules themselves, including the core factor table and edition entitlements, sit in Oracle's processor core factor table and the database licensing information manual.
Data handling is a legal question, not an IT one
Collection output is not anonymous. It typically contains database account names, host names, schema names, and sometimes identifiers that map to real people in your organization.
Where that data is stored, who sees it, whether it leaves your jurisdiction, and when it is deleted are all questions for counsel and your privacy function. Settle them in the protocol rather than after the file has been uploaded.
If Oracle has engaged a third party to perform collection, ask in writing who they are, what their engagement terms say, and whether your data will be held by them.
Run Java as a separate track
Java SE is a different metric, a different evidence base, and frequently a different Oracle team. Folding it into a database audit means arguing two unrelated cases in one conversation.
The evidence is download records and endpoint inventory rather than database views, and the current Oracle Java download terms reach an entire employee population rather than a server count.
Our Oracle Java licensing brief and the Java licensing pillar cover the metric and the migration options. Scope Java separately, in its own protocol section, with its own timeline.
What do you measure before Oracle does?
Your own estate, on your own terms, in four passes. The counter audit exists so that you know the answer before you are told it.
The four passes
- Deployment inventory. Every host, cluster, virtual machine, container, and cloud workload running Oracle technology, with an owner and an environment class.
- Metric mapping. Which metric applies to which deployment under your contract, including core factor, edition, and any negotiated definition.
- Entitlement reconciliation. Which ordering document covers which deployment, matched to support identifiers.
- Gap analysis in both directions. Where deployment exceeds entitlement, and where you hold entitlement nobody is using.
The fourth pass is the one buyers skip. Surplus entitlement is real, it offsets shortfall in the same product family, and it is invisible unless somebody goes looking for it.
Nothing runs on a host you have not inventoried
Collection scripts should execute only against hosts that already appear on your inventory with a named owner and an environment class. If a script would touch a host you cannot classify, classify it first.
Reviewing output before release is the highest return hour in the entire audit. Our guide to reading LMS script output covers the views column by column, and the wider defense sequence sits in the Oracle license audit defense playbook.
Where the common advice on the first 30 days is wrong
The common advice is to stand up a large cross functional task force on day one and start gathering data in parallel with the scoping conversation, so that you are ready when Oracle asks. We disagree. Parallel collection before scope is agreed is precisely how unscoped data leaves the building, and once it has, you spend the rest of the audit explaining findings drawn from an estate nobody agreed to look at. The first thirty days should be almost entirely paper: the clause, the closure letter, the ordering documents, the structure chart, and the protocol. Scripts are a week four activity at the earliest, and never before somebody has signed the scope.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Almost nothing that happens in an Oracle audit after week five was decided after week five. It was decided by what you agreed to, in writing, before anyone ran anything.
White Paper · Oracle
The Oracle Buyer Side Framework
The moves we use across Oracle Database, Java and ULA estates. Read it free.
What do you actually send Oracle, and how?
A reviewed package with a covering memo, not a folder of raw output. The difference between those two is most of the value in the first thirty days.
What goes in the package
- A covering memo. What is enclosed, what scope it covers, the date range, and the basis on which it is provided.
- The agreed dataset. Exactly what the protocol specified, and nothing beyond it.
- Your reconciliation. Detected, reviewed, and entitled, presented as your position rather than as raw data.
- Your exclusions, documented. Every row you removed, with the reason and the evidence.
What stays behind
- Raw unreviewed script output that nobody on your side has read.
- Internal opinions, draft assessments, and anything written before privilege was established.
- Architecture diagrams, roadmaps, and migration plans that were not requested.
- Data about entities, environments, or products outside the agreed scope.
- Console screenshots, which prove nothing useful and frequently prove something unhelpful.
Keep a data register
Log every file you send: name, date, recipient, scope covered, and a checksum. Keep the register from the first transmission rather than starting it when a dispute appears.
When a finding cites data you did not send, or attributes a host to a scope it was never in, the register is what settles the question in one message instead of six.
The first thirty days, day by day
| Days | Owner | Action | Artifact produced |
|---|---|---|---|
| 0 to 3 | Single point of contact | Acknowledge receipt, request clause and proposed scope | Acknowledgement letter |
| 1 to 5 | Sponsor and counsel | Stand up the team, issue the privilege instruction, lock the channel | Team mandate and privilege memo |
| 3 to 10 | Procurement and legal | Recover contracts, closure letters, ordering documents, structure chart | Contract and entitlement register |
| 5 to 20 | Contact, counsel, advisor | Negotiate the ten clause protocol, in writing, both signatures | Signed audit protocol |
| 10 to 25 | SAM and infrastructure | Run the counter audit across the four passes | Inventory, metric map, reconciliation, gap analysis |
| 20 to 30 | Contact and advisor | Review collection output, assemble and send the package | Covering memo, dataset, reconciliation, data register |
What happens after day thirty belongs to two other guides. The mechanics of contesting a specific line sit in challenging Oracle audit findings, and the commercial close sits in the Oracle audit negotiation guide.
The contractual foundation underneath all of it, including the clause, the notice period, and what Oracle can and cannot compel, is set out in our Oracle license audit overview and the full Oracle audit guide.
What should a buyer do next?
- Name a single point of contact today and give them a written mandate from the executive sponsor.
- Send the acknowledgement inside five business days. Confirm receipt and process, concede nothing else.
- Have counsel issue a privilege instruction before anyone writes down a compliance opinion.
- Recover the executed agreement, every ordering document, and any prior audit closure letter.
- Build the corporate structure chart and identify which entities actually signed Oracle paper.
- Draft your version of the audit protocol first, so Oracle is responding to your document rather than the reverse.
- Enumerate every environment class and settle how each will be treated before collection.
- Agree data handling in writing: storage, access, transfer, retention, and deletion at close.
- Scope Java as a separate track with its own evidence base and timeline.
- Run the counter audit, review every output file before release, and start the data register with the first transmission.
- Bring in independent audit defense before the first substantive reply, not after the findings land.
Redress Compliance is independent and buyer side. We do not partner with Oracle and we do not resell Oracle. If you have received a notice or expect one, the next step is a confidential briefing before you answer it.
Frequently asked questions
How quickly do we have to respond to an Oracle audit letter?
Acknowledge within five business days, in writing, from one named person. The standard clause gives Oracle a 45 day notice obligation before the audit begins, and it sets no deadline for your data. Acknowledging quickly and conceding nothing is the correct combination.
Who should reply to Oracle during an audit?
One named single point of contact, usually a senior procurement or SAM lead, with everything copied to counsel. Engineers, managers, and executives feed that person and never correspond directly. Uncontrolled contact is the most common self inflicted damage in the first month.
Do we have to let Oracle run scripts on our systems?
The standard clause requires cooperation and reasonable assistance and access to information. It does not name a tool or grant system access. In practice you run the scripts yourself, on hosts named in an agreed protocol, and review the output before any of it is released.
What is an audit protocol and is Oracle obliged to sign one?
An audit protocol is a written agreement covering entities, programs, period, environments, method, execution, data handling, communication, milestones, and closure. Oracle is not obliged to sign one, but it routinely does, because the alternative is a dispute about what was ever agreed.
Can we refuse to send data outside our country?
You can raise it, and you should. Collection output contains account names and host names, so transfer and storage are legal and privacy questions rather than IT ones. Settle jurisdiction, access, retention, and deletion in the protocol before any file is uploaded.
Should we tell Oracle we think we are out of compliance?
No, and you should not write it internally either until privilege is established. Preliminary assessments are usually wrong in both directions. Establish the facts under counsel's direction, then present a reconciled position rather than an early impression.
What if we find surplus licenses during the counter audit?
Document them carefully, because surplus entitlement in the same product family offsets shortfall and is routinely missed. Buyers look only for gaps. The fourth pass of a counter audit exists precisely to find entitlement that nobody has deployed.
How long should the first phase of an Oracle audit take?
Two to ten weeks from letter to a signed protocol, depending on how many entities and product families are involved. Where the buyer sets the pace it lands at the longer end, and that is the desirable outcome rather than a delay to apologize for.
