Preparing for a software audit

A software audit letter arrives with a deadline and a request for records that most organisations cannot produce quickly. The gap between what you can evidence and what you actually own is where the cost comes from, and it is usually a records problem rather than a genuine over-deployment.

The work that makes an audit manageable is done before the letter arrives.

What is actually requested

The specifics vary by vendor, but the shape is consistent.

Proof of entitlement. What you are licensed for. This means purchase records, licence certificates, agreement documents and any amendments. Reseller invoices alone are often insufficient; the vendor typically wants their own entitlement records to match yours.

Deployment data. What is actually installed and running. Usually collected by a script or tool the vendor provides, or from your own inventory system if it produces acceptable output.

Infrastructure detail. For anything licensed per core, socket or processor, the hardware specification of every host. For virtualised environments, the cluster configuration, because licensing frequently depends on where a virtual machine could run, not only where it does run.

Usage records. For subscription and user-based licensing, who has access and when they last used it.

The records to keep, continuously

Entitlement documentation, in one place. Every purchase, with the agreement number, the quantity, the metric, the date, and any amendments. Scattered across procurement mailboxes and individual managers' folders is the normal state and it is the reason audits take weeks.

Deployment inventory, current. What is installed where, refreshed automatically. If your inventory is a spreadsheet updated occasionally, an audit will find discrepancies you cannot explain.

Hardware specification per host. Cores, sockets, processor model, and the date each was commissioned. For clusters, the full member list and the configuration that governs where workloads can move.

Virtualisation configuration history. This is the detail that most often causes unexpected exposure. Several major vendors license per physical host on which the software could run. A permissive cluster configuration can therefore mean you are liable for every host in the cluster, not the two the software runs on.

Change history for the above. Being able to show when a host joined a cluster, or when a deployment was removed, resolves questions that would otherwise be assumed against you.

Where over-deployment usually comes from

Genuine deliberate under-licensing is rare. The common causes are structural.

Virtual machine sprawl. Templates cloned for a project, never decommissioned, still running licensed software.

Cluster expansion. Hosts added to a cluster for capacity, without anyone considering that the licensing metric is now larger.

Disaster recovery and test environments. Frequently assumed to be free. Sometimes they are, under specific conditions in specific agreements. Often they are not, and the conditions are precise.

Bundled components activated later. Software installed as part of a suite, with an advanced feature enabled during troubleshooting and never turned off. Some vendors license those features separately.

Version upgrades. An entitlement for one version does not automatically cover the next. Upgrades performed operationally, without checking the agreement, create exposure quietly.

Staff changes. Named-user licences reassigned informally, or leavers whose accounts remain active and consuming a seat.

An internal review before you need one

Run the audit on yourself, annually. It takes a few days and it changes the outcome of a real audit substantially.

1. Pick your three highest-value vendors by spend. That is where the exposure is.
2. Gather the entitlements for each. Note anything you cannot find documentation for.
3. Run the deployment discovery your inventory tools support.
4. Compare, per licence metric. Not per installation count, but per whatever the agreement actually counts.
5. Investigate each discrepancy. Some are genuine over-deployment. Many are entitlements you own and cannot evidence, which is a filing problem with a real cost.
6. Remediate. Uninstall what is not needed, reassign what is misallocated, reconfigure clusters where the licensing implication is unfavourable, and buy what you genuinely need before it is found.

That last step matters. Purchasing to correct a shortfall you identified yourself is an ordinary commercial transaction. Purchasing under audit is not, and the terms reflect it.

When the letter arrives

Acknowledge and agree a timeline. The initial deadline is usually negotiable. Rushing produces incomplete data that is interpreted unfavourably.

Establish one point of contact. Multiple people answering the same auditor with slightly different information is how inconsistencies appear.

Read the audit clause in your agreement. It defines what you are actually obliged to provide, how much notice is required, and what the scope is. Vendors sometimes request more than the clause entitles them to.

Review the data before sending it. Understand what it shows, and have your explanation ready for anything that looks like a discrepancy. Data sent without review invites conclusions.

Keep a copy of everything provided. You will need it if the findings are disputed.

Get advice before signing anything. Findings are frequently negotiable, particularly where the cause is a records gap rather than genuine over-deployment.

The point of all this

Software audits are routine commercial activity, and vendors conduct them because they are usually profitable. What makes them expensive is a customer who cannot demonstrate what they own.

The organisations that come out of audits well are not the ones with perfect compliance. They are the ones who can produce entitlement and deployment records in days rather than weeks, and who found their own discrepancies first.