An audit notification rarely lands with the people who can answer it. A software audit task force brings the right stakeholders together, defines who is accountable for what, and gives the response a single voice.
A software audit task force brings together everyone in your organisation who will need to play a part in responding to a publisher’s audit request, and in getting through the process as smoothly and safely as possible.
The notification will typically arrive as an email or letter, either from the software publisher directly or from an auditor they have appointed. It rarely goes to the ITAM or SAM team. Far more often it goes to whoever last signed the contract — someone in procurement, or a senior manager who has not thought about that agreement in three years.
That routing problem is the reason this article exists. When the request comes in, the ITAM/SAM team need to be told immediately, so they can convene the task force before anyone replies to the publisher.
A software audit task force exists to orchestrate a safe and effective response.
It is a collaborative working group that keeps stakeholders informed at every stage, and lets them formulate, govern and execute a strategic response rather than a series of individual reactions. Audits go wrong when different parts of the business answer the same question differently, or when someone concedes a point in an email that the licensing team would have contested.
One group, one position, one voice to the publisher.
The key is to never assume that the stakeholders you need already understand the software audit process. Most of them will never have been through one.
For the task force to function, its purpose and the roles and responsibilities within it have to be communicated explicitly and understood. That guidance and structure should come from the ITAM/SAM team, with the visible backing of the business — because the group will be asking senior people for time they had not planned to give.
Stakeholders would typically include, but need not be limited to:
Software Asset Management — responsible for coordinating the task force, licence compliance and cost optimisation.
Finance — audits can be expensive. Payments may need to be structured.
Procurement — essential for gathering licence entitlement data and for contract negotiation.
Senior Manager — a nominated single point of contact with the publisher or auditor. One person. Not a committee, and not whoever happens to reply first.
Commercial — the revenue-generating side of the business needs to be informed and consulted on software strategy, particularly if any products may have to be removed.
IT Service Delivery — responsible for ITAM and SAM operations, and for how the business actually consumes software.
IT Service Desk Manager — responsible for performing the actions the audit requires, including removal of unlicensed or unapproved software.
IT Risk Management — responsible for security within software policy.
Legal — for a clear reading of the existing contracts, and for negotiating audit clauses in whatever comes next.
Budget holders — affected by any commercial change to licensing contracts or costs.
IT Security — overall responsibility for security across the software asset lifecycle.
Beyond the standing membership, identify the stakeholders who will vary case by case:
It is good practice to use a RACI matrix to define who is responsible, accountable, consulted and informed at each step. Do this at the start, while the discussion is still calm. Working out who owns a decision in the middle of a disputed finding is not a productive use of anyone’s week.
The task force can only be as good as the evidence it has to work with. Two things determine that.
The first is whether you already hold a licence position, or have to build one under time pressure. CerteroX SAM computes the effective licence position continuously — purchased, used, available, required, variance and exposure — rather than assembling it when the letter arrives. The task force’s first meeting is far shorter when the answer to “where do we think we stand?” already exists.
The second is whether you can show your working. An audit turns on evidence, and the audit trail across agreements, transactions, entitlement records and licensing exclusions is what supports the position you put forward. Where the audit is scoped to a specific legal entity, region or business unit, reporting levels restrict visibility accordingly, so what you produce matches what was agreed rather than exposing more than the publisher asked for.
That is a subject in its own right, and it is covered separately — including how audits are triggered, what the phases look like and where organisations most commonly lose ground.
If you would like help understanding the process, defining the roles and responsibilities of your stakeholders, or navigating an active publisher audit, speak to us.
Other posts covering the same ground.
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.
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.
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.
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.