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.
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.