The IT Director's Java compliance handbook

For most of your career, Java was not a line item and not a risk — it was free infrastructure that just worked. That assumption is now a liability. Oracle’s 2023 move to an employee-based Java SE metric, combined with a sustained audit programme, has turned Java licensing into a genuine financial exposure for almost every enterprise — and as IT Director, it is your name against it. This handbook is written for that reality: what you should personally own, the questions to put to your team, the governance to install, and how to brief leadership before Oracle does it for you.

Why Java is now your problem

Three changes turned Java from background infrastructure into a director-level concern. First, the metric. Oracle’s Java SE Universal Subscription is priced per employee — counting your whole organisation, not your Java users — so the potential cost is large and scales with headcount rather than usage. Second, enforcement. Oracle actively reviews Java deployments and issues audit and “soft audit” approaches, and a finding can produce a seven-figure claim with no warning. Third, sprawl. Java is everywhere — servers, desktops, containers, embedded in third-party products — and most of it was installed by people who never thought about a licence.

The result is a risk with an unusual profile: high potential cost, low organisational visibility, and no natural owner. Finance does not see it because it was never budgeted. Procurement does not see it because nothing was bought. Engineering does not see it because Java “is free.” That gap is exactly where exposure accumulates — and closing it is an IT Director’s job, because the IT Director is the one role with sight of the whole estate.

What an IT Director should own

You should not personally run Java discovery scans. But there are four things an IT Director must own — meaning hold accountability for, even if the work is delegated.

• Visibility. The organisation has an accurate, current picture of where Oracle Java runs and under what licence. If that picture does not exist, that is your first accountability.
• The risk position. You can state, in financial terms, what the Java exposure is and how confident you are in the number. Leadership will eventually ask; you should not be discovering the answer when they do.
• The strategy. There is a deliberate decision — subscribe, migrate, or a managed mix — rather than a default of doing nothing.
• The governance. Controls exist so that new Java exposure cannot be created silently by a developer or a vendor after today.

Notice what is not on the list: writing the inventory, choosing a JDK build, running a migration project. Those are delegated. What you own is that they happen, that the numbers are honest, and that the strategy is a choice.

The questions to ask your team

You can establish your position quickly by asking five questions and listening hard to the quality of the answers. Vague answers are themselves the finding.

1. “Where does Oracle Java run across our estate, and how do we know?” The right answer cites a recent automated discovery scan. “We think mostly on the app servers” is not an answer.
2. “Which of our Java is Oracle-licensed and which is free OpenJDK?” This split is the exposure. If nobody can draw the line, the exposure is unknown.
3. “Do we have a Java SE subscription, and what exactly does it cover?” A subscription that under-covers the estate is as risky as none at all.
4. “What stops an engineer installing Oracle JDK tomorrow?” If the answer is “nothing,” you have no governance — exposure can grow faster than you remediate it.
5. “If Oracle sent an audit letter on Monday, what would we do?” The absence of an answer is the answer.

These five questions take an afternoon and tell you almost everything. An organisation that answers all five crisply is in good shape. One that fumbles three or more has real, unmanaged exposure — and now you know.

Putting Java governance in place

Discovery tells you where you are; governance keeps you there. Without it, every remediation is undone by the next unreviewed install. Effective Java governance for an enterprise rests on a few controls:

A standard, approved runtime. Decide which JDK the organisation uses by default — for most, a free OpenJDK distribution — and make it the path of least resistance: in the golden images, the container base images, the developer setup.

A control on Oracle JDK. Installing an Oracle-licensed JDK should require explicit approval, not a default. The most common cause of new exposure is an Oracle binary pulled in through a routine download or update; a simple approval gate stops it.

Procurement and vendor checks. Third-party software frequently bundles Java. New software purchases should be screened for an embedded Oracle JDK and its licensing status — before it is in production, not after.

Ongoing monitoring. A one-time scan ages immediately in a dynamic estate. Java discovery should be recurring, so the picture stays current — the principle behind continuous compliance.

Reading and sizing the risk

To manage Java as a risk you have to size it, and the sizing has two components: likelihood and magnitude. The magnitude is, broadly, what Oracle could claim if every Oracle binary in your estate were treated as requiring a subscription under the employee metric — a number driven by your headcount. The likelihood is the chance Oracle turns its attention to you, raised by signals such as past Oracle downloads tied to your domain, lapsed legacy subscriptions, or a related Oracle product relationship.

You do not need actuarial precision. You need a defensible range and an honest confidence level, because that is what converts Java from a vague worry into a managed line. The good news for an IT Director is that both components are reducible. Magnitude falls when you replace Oracle binaries with free OpenJDK. Likelihood-of-a-bad-outcome falls when you hold clean, current evidence of your position. Across 340+ Java engagements, that preventive posture has contributed to a 68% average reduction in the audit claims that did arise — the difference between a managed risk and an unmanaged one.

Briefing the board

At some point Java licensing reaches leadership — ideally in a slide you chose to present, not a claim Oracle delivered. A good board briefing on Java is short and does four things. It states the exposure as a range with a confidence level. It explains, in one line, why the risk exists now when Java was always free before — the employee metric. It presents the strategy options — subscribe, migrate, managed mix — with their costs. And it asks for a specific decision or mandate, so the board owns the chosen path with you.

The framing that lands is “here is a risk I have identified, sized, and have a plan for,” not “here is a problem.” An IT Director who brings Java to the board on their own terms looks like someone managing risk well. One whose board first hears about Java from an Oracle audit letter looks like the opposite — for the same underlying facts. Controlling the timing of that conversation is one of the highest-value things in this handbook.

Setting a Java strategy

Every enterprise ends up on one of three Java strategies, and the IT Director’s job is to make it a choice. The first is subscribe — pay Oracle for a Java SE subscription that genuinely covers the estate. Appropriate where Oracle Java is deeply embedded and migration is genuinely hard; the discipline is to negotiate it properly rather than accept the first quote. The second is migrate — move the estate to free OpenJDK and reduce Oracle Java licensing cost toward zero. For most enterprises whose Java has no hard Oracle dependency, this is the strongest long-term answer. The third is a managed mix — a small, deliberately licensed Oracle footprint where it is truly needed, free OpenJDK everywhere else. The wrong “strategy” is the fourth, unspoken one: drift — no decision, no owner, exposure growing. Your contribution as IT Director is to retire drift and put one of the three real strategies on the record.

A 90-day plan

If you are starting from a standing position, this is a realistic first quarter:

• Days 1–30 — See. Commission a full Java discovery scan and ask the five questions. End the month with an honest inventory and a draft exposure range.
• Days 31–60 — Decide. Validate the inventory, split Oracle from OpenJDK, model the three strategies with costs, and choose one. Draft the board briefing.
• Days 61–90 — Govern. Stand up the governance controls, begin the first remediation, and brief leadership on the risk, the plan, and the decision needed.

Ninety days is enough to move from “we don’t really know” to “we have an inventory, a sized risk, a chosen strategy, and governance in place.” That transition is the entire job this handbook describes.

Getting independent help

Java licensing reached the IT Director’s desk because of a change you did not ask for — an employee-based metric and an enforcement programme that turned free infrastructure into a financial risk. The handbook’s message is that this risk is entirely manageable: it just has to be managed, with a named owner, a current inventory, a sized exposure, a chosen strategy, and real governance.

Independent, buyer-side advisers accelerate every step of that — the discovery, the honest exposure number, the strategy modelling, the board-ready briefing — with no Oracle partnership shaping the advice. Our Java Compliance Assessment gives you the inventory and the risk range, our Migration service executes the migrate strategy, our Negotiation service handles the subscribe strategy properly, and our Audit Defence service, backed by a money-back guarantee, stands behind you if an audit arrives. Across 340+ Java engagements, that support has contributed to more than $180M in client savings and a 68% average audit claim reduction.

Frequently asked questions