What Triggers a Software Audit: The Seven Signals Vendors Act On
Software audits are not random. Vendors have a limited number of auditors and a long list of customers, and they point the auditors where the expected recovery is highest. The events that raise a customer to the top of that list are knowable, most of them are visible from the vendor's side of the relationship, and several are things the customer did on purpose for good reasons. Knowing the triggers does not stop an audit. It tells you when to have the position ready.
This is the list as it stands for the major publishers, with what each trigger looks like from the inside and what to do about it.
1. A renewal or true-up is coming
The most reliable trigger of all. In the twelve months before a large agreement expires, the vendor's account team has every incentive to establish a compliance gap it can convert into a bigger renewal, and audit teams are frequently briefed on upcoming renewals. Microsoft's true-up cycle and Oracle's support renewals both produce a wave of reviews. If the renewal is within a year, assume the audit is too, and build the position before the first meeting.
2. A drop in spend
Reduced support, cancelled subscriptions, a smaller true-up than last year, or a move of workload to a competitor. The vendor reads a decline in revenue as a change in the estate it has not verified. Broadcom's approach to VMware perpetual customers who declined subscriptions is the clearest recent example; Oracle's response to support terminations is the classic one. Cutting spend is right; doing it without a position that shows the remaining deployment is licensed is what turns it into a review.
3. Mergers, acquisitions and divestitures
A merger brings two estates, two sets of agreements, and a period in which nobody is certain which licences cover which systems. Vendor agreements often restrict transfer of licences between legal entities, and an acquired company's deployment may fall outside the acquirer's agreement for months. Vendors watch the press releases. An audit notice arriving six to twelve months after a deal closes is standard practice.
4. Infrastructure change the vendor can see
A migration to a new hypervisor, a hardware refresh, a move to or from a cloud provider, a virtual desktop rollout. Some of these are visible to the vendor through support tickets, some through its own telemetry, some through the partner who sold the new platform. Each one changes the counting rules that apply, and vendors know that customers rarely re-baseline after a platform change. Hypervisor choice is the sharpest case for Oracle; for Microsoft it is the shift to virtual desktops and to per-user metrics.
5. Telemetry, downloads and product registrations
Java is the modern reference. Oracle can see downloads of the JDK from its own site by corporate IP range and matches them to customers without a Java SE subscription. Adobe sees activations. Microsoft sees tenant configurations. SAP sees indirect access through interfaces. A download by one developer is enough to start a conversation, and the conversation is about the whole employee count under the current Java SE metric.
6. Partner and whistleblower reports
Resellers and consultancies report suspected under-licensing to the vendors they partner with, sometimes because their agreements require it. Former employees do too; the BSA and similar bodies pay for it. Neither is common in enterprise estates, but both exist, and both arrive without warning.
7. Silence
A customer that has not engaged with the vendor for years, has not bought anything, and has not been audited recently is, in the vendor's model, an estate whose deployment has drifted from its entitlement by the normal rate of change. Long, quiet relationships get reviewed on a cycle, typically every three to five years, simply because the expected gap has grown.
What an audit notice actually starts
The letter names the products, the entity and the scope, and quotes the audit clause of your agreement, which sets the notice period and the tools you must run. From that point the sequence is fixed: kick-off, data collection with the vendor's scripts, a preliminary findings report, a dispute period, a settlement. Every stage is shorter than it sounds and every stage assumes you can produce entitlement records, deployment data and infrastructure detail on request. Teams without that on hand negotiate from the vendor's numbers.
The preparation that makes the trigger irrelevant
- A current Effective License Position for each audit-prone vendor: Oracle, Microsoft, IBM, SAP, Adobe, and now Broadcom. Not a compliance score; a reconciliation with evidence.
- Entitlement records that are findable. Ordering documents, agreements and their amendments in one place, indexed by product and entity.
- Your own script runs, on the vendor's tools, at least annually and before every change on the list above. If the vendor's script will find it, find it first.
- An audit response playbook: who receives the notice, who speaks to the vendor, what data leaves the building and under what agreement, and where the position lives.
- Infrastructure data that maps to licensing rules: clusters, sockets, cores, CPU models, VM placement history. The rules are the vendor's; the data has to be yours.
Most of that list is a data problem before it is a licensing problem. The estates that handle an audit in weeks rather than quarters are the ones where the deployment data flows continuously into a position, so that the renewal, the acquisition or the migration is already reflected when the letter arrives. That is what LICENSEWARE's audit defence work rests on, and it is the reason the apps take the vendor's own script output as input: the audit is a comparison of your numbers with theirs, and the numbers should already be the same.
The triggers will keep changing with each vendor's revenue pressure. The response does not. Whatever puts you on the list, the only thing that shortens the audit is a position you built before it started.
