Software audits are disruptive. They consume time, tie up internal resources and, if you are unprepared, produce significant unbudgeted spend. With the right approach they are manageable, and they do not need to end in panic or unnecessary cost.
This article sets out how vendor audits typically work, what to expect at each stage, and the practical steps to take now.
What is a software audit?
A software audit is a formal request by a vendor, or an auditor appointed by them, to review your software deployments, usage and entitlements against your licensing terms.
Audits are triggered by mergers and acquisitions, rapid growth, expired contracts, or simply having the “wrong” product mix. Sometimes a vendor decides it is your turn.
Most enterprise licence agreements include audit clauses. Ignoring a notification or stalling a response is not usually a viable option.
It is also worth understanding who conducts the audit. The appointed auditor is frequently one of the large accountancy firms — Deloitte, EY or KPMG. They are presented as independent third parties, and they are paid by the software publisher. Their findings should be read with that context in mind. They are not fully neutral, and their work ultimately serves the vendor’s interests.
For some publishers, auditing is not only a compliance mechanism but part of the commercial model. Vendors that acquire companies with widely deployed products have been known to audit the inherited customer base energetically, recovering acquisition cost through compliance settlements rather than through new licensing and support. If you run products that have recently changed hands, expect audit activity and prepare for it.
How the audit process works
Every audit differs in detail. Most follow the same six stages.
1. Notification
The audit begins with a formal letter, from the vendor directly or from a third-party auditor acting for them. You will need to acknowledge it, understand the scope, and confirm the legality of the request against your contract.
Be aware that audit notifications can be sent to anyone in the organisation who has ever accepted a EULA, including former employees. That causes delay and missed communication when the recipient has left or the agreement was never centrally recorded. It is a strong argument for a proactive SAM programme: agreements tracked centrally, and staff trained to escalate any vendor communication promptly.
Confirm and agree the operative contract the audit is being conducted under. Most enterprise agreements include audit rights, but audits have been initiated on the basis of outdated, informal or inapplicable agreements that granted no such right — and in some cases by auditors with no contractual authority at all. Verifying the legal basis belongs in the first few days, not the last few.
Finally: changes to your environment after an audit notice arrives — uninstalling software quickly, decommissioning servers — can be detected from historical data and system timestamps, and will be flagged during data collection. Any change you make should be considered, documented and justifiable on its own merits, audit or no audit.
2. Kick-off
An initial meeting defines timelines, data sources, scope and deliverables. Get clarity here or you will spend the rest of the audit fighting scope creep.
Before that meeting, stand up a core response team: IT, procurement, software asset management and legal. Agree a single point of contact with the auditor, and route every communication through the team.
Meet in advance to align strategy, particularly if you already know where the compliance risks are, or if you are planning to significantly increase or decrease usage of the vendor’s products.
Raise any mitigating circumstances at this stage — limited availability of key personnel, an in-flight migration that will distort inventory and usage data, or the need for a non-disclosure agreement before sensitive information changes hands. Flagging these early sets realistic expectations and can adjust the timeline or the scope.
Brief the single point of contact properly. Centralised messaging avoids contradictory answers and keeps control of the process where it belongs.
3. Data collection
You will be asked for inventory reports and usage details for the products in scope. Vendors may also require you to run specific discovery tools or scripts.
Understand exactly which products are in scope and what data genuinely supports the audit. Some requests reach beyond the agreed scope, or fish for evidence that inflates deployment figures: dormant installations, legacy environments, remnants of uninstalled software. Scrutinise them, and share only what is relevant and appropriate.
Some audit data — usernames, device names — is sensitive from a security or data protection perspective. Consider masking or anonymising it, and agree acceptable data handling practices with the auditor in writing.
4. Initial findings
The auditor reviews your data and shares a draft summary of potential risks or shortfalls. This is a draft. Treat it as one.
5. Review and response
You have an opportunity to review the findings, clarify, and contest incorrect assumptions. The quality, accuracy and completeness of your own data decides whether you can challenge the report at all, and whether you negotiate from strength or from hope.
Auditors will often push for a quick sign-off. Do not agree to anything under pressure. Take the time to understand what is presented, review each line item, and gather your responses and objections in a coordinated way.
Audit reports frequently arrive in complex, hard-to-interpret formats with little or no commercial context. This is intentional. A minor-looking figure can represent a substantial cost once the vendor applies commercial terms. Question any unexplained metric or assumption before you accept the report.
Reports also tend to include entitlement data supplied by the publisher. You might expect that to be authoritative. It is not. It is often pulled by keyword search from the vendor’s internal systems and can be incomplete — missing entire business units, historical purchases, or bundled entitlements. Always compare their entitlement view against your own records.
6. Resolution
If non-compliance is confirmed, the vendor will expect a commercial resolution: a licence purchase, a contractual amendment, or a backdated support agreement.
Anything you failed to settle during review and response now gets negotiated with commercial terms attached, which makes technical findings much harder to shift. Stay firm, stay organised, and stay documented.
Your future requirements are negotiating power. Planned product adoption, upcoming renewals and the broader vendor relationship all carry weight — and vendors are noticeably more flexible near quarter-end or fiscal year-end, when they are under pressure to book revenue. Time the negotiation accordingly.
Once the audit closes, hold a lessons-learned session with the response team. What worked, what did not, and which gaps in process, tooling or data quality need closing before the next letter arrives.
TL;DR
- Run regular internal licence reviews — Effective Licence Position assessments — to find and close compliance gaps before an audit finds them for you
- Centralise entitlement management so licence records are complete, accurate and immediately available
- Maintain a reliable audit trail of software deployments, removals and usage, especially for high-risk or high-value applications
- Educate staff to escalate vendor communications and EULA acceptances, and to understand why software controls exist — not to limit productivity, but to protect the organisation from financial, legal and security risk
- Establish a cross-functional audit response team in advance, so IT, procurement, SAM and legal are already aligned when the letter arrives
What this looks like in CerteroX SAM
Every item in that list is a capability, not an aspiration. Here is how CerteroX SAM covers them.
A licence position that is already current. CerteroX SAM computes an Effective Licence Position continuously rather than reconciling at a point in time: purchased, used, available, required, variance and exposure, with the overspend and additional-licences-required calculations alongside. When a notification arrives, you are reading a position, not starting a project.
Depth on the publishers that actually audit. Dedicated engines for Microsoft, Oracle, IBM, SAP, Adobe and Salesforce. For Oracle that means options and packs with evidence and override, processor types and core factors, licence pools with hosting rights and geographic rules, cover-down logic for Enterprise Edition, and E-Business Suite responsibilities. For Microsoft it means device and user CALs, named user and external connectors, and SQL Server and Windows Server core and processor licensing with cluster and virtualisation awareness. Generic install counts do not survive contact with either.
IBM sub-capacity, done to the standard IBM sets. PVU and Virtual Processor Core metrics, an ILMT connector with compliance gap analysis, Component Resolution that matches deployed components to products with a scored suggestion, and enforcement of the 30-minute inventory cycle that sub-capacity licensing actually requires.
Oracle-verified measurement data. Certero is a verified third-party tool vendor for Oracle License Management Services. As Certero publishes it: “Being a verified 3rd party toolset means that Oracle’s audit team can accept data from Certero for Oracle during an official audit, as an alternative to installing Oracle License Management measurement tools.”
Centralised entitlement, in one place. Licences, transactions, agreements, maintenance, suppliers and publishers; per-device, per-processor and per-core assignment; Microsoft Licence Statement import; volume, retail, OEM and FPP transaction capture; subscription flags with expiry tracking; purchase order and invoice capture. This is the record you compare against the publisher’s keyword search.
The audit trail, kept as you go. Full history across agreements, transactions and exclusions, plus the Exclude From Licensing workflow for MSDN, development, training and second-use devices — which is precisely the category auditors inflate when it is undocumented. Software usage is metered from first-used and last-used data against a rolling ninety-day window, so “installed but never opened” is a claim you can evidence.
Preparation is the whole game. Talk to us about where your position stands before someone else asks.