Skip to content

Software Audit Defence Tactics

Ten questions organisations ask when a publisher audit lands — on the right to audit, delaying it, limiting scope, dictating tools, challenging findings and negotiating the settlement — with the honest answer to each.

Responding to a publisher audit can disrupt a whole year of planned work, and that is before the bill for any licensing shortfall. Software audits are a strategically timed, revenue-generating activity for publishers — that much is simply true. But there are tactics that limit the impact, and occasionally prevent the audit altogether.

What follows is the set of questions organisations ask most often when the letter arrives, and the honest answer to each.

Does the publisher actually have the right to audit?

Before anything else, assemble a software audit task force. It should include stakeholders from across the business, and Legal in particular can be extremely useful in querying whether the request is valid at all. Occasionally it is possible to deny the request and avoid the audit entirely.

Ask your legal team to qualify four things:

  • Does the agreement with this publisher actually contain an audit clause?
  • Does your contract include any bespoke clauses that limit or prohibit a request to audit?
  • Is the request made against the most recent contract, or an older one that has since been superseded?
  • Is there a potential conflict of interest with the third-party auditor — have they audited you recently on behalf of a different publisher?

None of these are obstructive questions. They are the minimum due diligence before you commit budget and staff time to a process you may not be obliged to undertake.

Can you delay a publisher audit?

Audits are usually mandatory in the end, but the publisher should recognise that one represents unplanned work for you. It is common to be given a period — frequently around 45 days — to formally acknowledge the request, though the publisher will usually push for a kick-off meeting considerably sooner than that.

There are reasons a delay can be reasonably requested:

Workload. A major system launch or roll-out already in flight is a legitimate business reason to move the start date.

Personnel. Are the stakeholders you need actually available? Short-term absences are usually accommodated. Long-term ones should already have cover arranged, and arguing otherwise weakens the position.

Legal and due diligence. Validating the audit request takes time, as does negotiating and signing a non-disclosure agreement.

Other audits. One audit tends to follow another, because publishers notice when an organisation lacks control. If you have recently been through the process with a different publisher, it is reasonable to ask for room.

One caveat, and it matters. Delaying an audit is legitimate. Using the delay to quietly correct licensing problems is not, and you should be careful never to give the impression that this is what is happening.

Can you limit the scope of an audit?

Once engaged, defining and agreeing the precise scope is essential. Scope is what prevents competing interpretations later, and what stops the publisher claiming to have “discovered” software on systems you believed were out of scope. If you are unsure, get independent expertise to clarify it before you agree to anything.

This is also the point at which scope can be negotiated — by product, by legal entity within your group structure, or by location and geographic region.

If the publisher will not negotiate scope, they will usually negotiate a non-disclosure agreement. Use it. Set boundaries on how information is shared and make sure what you provide is confined to data directly relevant to the questions the publisher is entitled to ask.

Can you dictate what tools are used?

General practice is to use the inventory tooling you already have. There are exceptions where that becomes difficult.

Data quality is the whole game in audit defence. The more you can prove, the more of your position you can successfully argue.

The risk arises where a publisher stipulates that it will only accept inventory data produced by its own tools or scripts, or by formally verified third-party tooling — because that can mean you have no visibility of what is being submitted on your behalf.

The notable cases:

Oracle. Oracle License Management Services will typically deploy its own scripts during an audit, which limits your visibility of the information going back. Oracle also maintains a list of formally verified third-party tool vendors, whose measurement data Oracle will accept. CerteroX SAM is verified by 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.” Read that precisely — it does not mean Oracle waives the audit. It means you can see your own Oracle position, and the data submitted, before Oracle does.

IBM. Contracts typically require customers running sub-capacity, virtualised environments to have the IBM License Metric Tool deployed, on pain of losing sub-capacity licensing rights and being licensed at full capacity instead. ILMT is notoriously awkward to run and configure correctly. CerteroX SAM includes an ILMT connector with compliance gap analysis, PVU and Virtual Processor Core metrics, Component Resolution to match deployed components to products with a scored suggestion, and enforcement of the 30-minute inventory cycle that sub-capacity licensing actually requires.

Microsoft. Microsoft has no formally verified third-party toolsets, despite a persistent belief to the contrary when certain tools show up repeatedly in audits. Tool selection by third-party auditors is generally driven by their own commercial arrangements with the tool vendor, not by Microsoft.

If you are using your existing tooling, you need to know whether it is up to the task. The auditor will specify the data they require, typically:

  • Device names
  • Users
  • Device types — physical or virtual
  • Environments
  • Hardware details: make, model, CPU, cores
  • Operating systems
  • Application details, including version and edition

And it will need to be submitted in accepted forms: exported reports from ITAM and SAM tooling, licence files, log files.

The challenge is making sure what you submit is accurate, because inaccurate data introduces risk you then have to argue your way back out of.

Two common pitfalls:

Inventory without recognition. A raw software inventory tells you a binary exists. It does not necessarily tell you what that software is in licensable terms — publisher, product, version, edition. If what you submit is vague, the publisher will interpret it in their own favour. Where it is unclear whether an install is a standard or a professional edition, expect the more expensive assumption, because you have provided no evidence to the contrary. This is solved at source rather than in the audit: CerteroX SAM resolves discovered software against a Software Recognition Database of more than 3.5 million titles, along with software identification tags and publisher normalisation, so what you hand over is already specific.

Coverage gaps. Configuration management tooling such as Microsoft SCCM is built for managing Windows clients, and coverage thins out on servers and anything that is not Windows. Those gaps become audit findings. CerteroX ITAM runs a native inventory agent across Windows, macOS, Linux, AIX, HP-UX and Solaris, with agentless and command-line inventory for locked-down systems and standalone inventory for air-gapped ones — so the non-Windows population is not a footnote in your submission.

Can you challenge the results?

Not only can you, you should. Validate every finding against your own effective licence position.

Software asset management is difficult to get exactly right, and publishers and their audit partners make mistakes — expensive ones, in both directions. Be prepared to challenge anything that does not look correct, and remember that interpreting audit data always involves a degree of assumption. The better your own information and the stronger your licensing knowledge, the more of those assumptions you can resolve in your favour, reducing both exposure and cost.

If the publisher is using a third party to conduct the audit, you may be able to review the findings before they are submitted to the publisher. Ask.

Can you get help during an audit?

Yes — before one, and during one. It brings two benefits.

The first is that the process becomes far less time-consuming and disruptive. An audit defence engagement supplies three things together:

Technology — to discover and accurately identify all the software in scope.

People — licensing experts, including specialists for the publishers that bite hardest: Microsoft, Oracle, IBM and SAP.

Process — guidance through the dialogue with the publisher, so you stay informed and in control of what is happening.

The second is cost. Audits are revenue-generating exercises. It is entirely fair that you pay for software you have had the ability to use — but expert audit defence makes sure you are not also paying for errors in the effective licence position, unfavourable interpretations of your contractual rights, or anything that should never have been in scope.

As long as you can evidence your licence position, the rules can work for you.

Can you negotiate a settlement?

Yes. You can always negotiate.

The best outcome of an audit, from the publisher’s point of view, is manoeuvring you into signing another lengthy and profitable agreement. So where an audit produces a significant settlement figure, the publisher will usually offset it against the cost of a new agreement and further investment in their products.

Remember that an audit is a sales activity. Salespeople are generally incentivised to close new volume licensing agreements, which means it is in their interest to negotiate. There is no escaping the fact that you owe money, and some publishers are far more insistent about collecting than others — but you can use that dynamic to limit wasted expenditure and to add clauses that reduce the chance of another unforeseen audit. A no-audit assurance covering the next two to three years is a common thing to ask for.

Can you delete software that is out of compliance?

No.

You cannot simply remove software you have deployed and used but not correctly licensed. You entered into the End User Licence Agreement when you deployed it, and attempting not to pay for it afterwards is, in substance, theft.

There is a practical consideration too. If the audit process ends up in court, any suggestion of dishonesty becomes extremely costly — and being publicly shown to have acted dishonestly does damage well beyond the settlement figure.

Can you control what data is submitted?

Yes, and you should. Everything submitted to the auditor should be accurate and approved by your audit task force before it leaves the building.

That is not the same as manipulating or falsifying it. Again: any suggestion of wrongdoing and the matter escalates well past a commercial disagreement.

You control the submission so that you understand the picture being presented, and so you do not volunteer anything unnecessary. It is private and confidential company information. Mark it as such, and keep the communications consistent.

How do you avoid audits altogether?

The only reliable way to avoid the cost and disruption is to manage software proactively and keep licensing optimised — either with the right tooling and expertise in-house, or through a managed service.

The objective is constant compliance rather than periodic reconciliation. When the publisher comes knocking, the information you need already exists, and it proves two things at once: that you are not under-licensed, and that you are not routinely overspending on software nobody needs.

If you would like help with a publisher audit, or with any aspect of IT asset management, talk to us.

Related reading

Other posts covering the same ground.

  • Device-based licensing and access control

    Locking an application down at user level does not make you compliant with a per-device licence. In a Citrix or RDS environment, one user with access can cost you a licence for every device in the organisation.

    • ITAM
    • SAM
    • Governance
    4 min
  • Gartner Myth Buster – Part 1

    A third-party summary of a vendor can be wrong, and it stays wrong for as long as people read it. The case for checking a vendor's facts at source — and the current, sourced record for Certero.

    • ITAM
    • SAM
    • Governance
    7 min
  • The role of good data in software audits

    An audit is won or lost on the quality of your inventory long before the letter arrives. Six ways data goes wrong, and what it takes to have the answer already in hand.

    • ITAM
    • SAM
    • Governance
    8 min
From reading to evidence

Put the hardest claim here
to a technical person.

Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.

No gated download at the end of it.