Software License Compliance and Audit Defense: Why Your Discovery Data Cannot Answer the Vendor's Question | Digital Heroes

Why the audit letter finds you unprepared even with a SAM tool installed

The letter arrives addressed to the CIO, referencing a clause in an agreement signed in 2011, and asks for deployment data within thirty days. The IT asset manager knows roughly where the contracts are: a shared drive folder, a contract management system that holds master agreements but not the ordering documents where the actual quantities live, and a former colleague's mailbox that was archived. The discovery tool can produce a list of installations by host within a day. What nobody can produce is the thing the vendor is actually asking for, which is a defensible statement of what you are entitled to deploy under those specific agreements, measured in the vendor's own units, at a specific date.

That gap is the whole subject. Discovery answers what is installed. Entitlement answers what is permitted. The compliance position is the difference between them, computed under rules that live in contractual text rather than in any product's default configuration. Most organisations have invested seriously in the first half and barely at all in the second, which is why the audit response becomes a scramble involving procurement, infrastructure, legal and an external adviser who charges by the hour.

The financial exposure is asymmetric in a way that makes this worth funding properly. Being over licensed costs you the shelfware, which is annoying and recoverable at renewal. Being under licensed on a core based database or virtualisation product, discovered during an audit, produces a settlement demand plus back maintenance and removes your negotiating position at exactly the moment you needed it. The same infrastructure change, a cluster expansion or a host added to a resource pool, can move you from comfortably compliant to materially exposed without anyone in the room realising a licensing decision was being made.

Problem one: entitlements live in prose and nobody has turned them into data

A licence entitlement is not a number. It is a quantity attached to a product, under a metric, subject to product use rights that vary by agreement and by the version of the vendor's policy document in force when you bought, modified by every amendment and true up since, and sometimes carrying migration or upgrade rights from a product you no longer run. Twenty years of that history sits in PDFs.

Turning it into structured data is unglamorous and it is the single highest value piece of work in this category. Each entitlement record needs the agreement it came from, the ordering document, the effective date, the quantity, the metric, the permitted versions and editions, any geographic or entity restrictions, and a link to the source page so an auditor or your own counsel can verify it. Document extraction helps with the first pass, pulling quantities, product names and dates out of ordering documents into draft records, but a human with licensing knowledge has to confirm every one. Anyone selling you a fully automated contract to entitlement pipeline is selling you a liability.

This is also where commercial tools underdeliver relative to their reputation. Flexera and Snow both carry genuinely valuable product recognition and normalisation libraries that would be foolish to rebuild, and both accept entitlement records. What they cannot do is interpret your negotiated clause. Their calculation engines encode a generic reading of each vendor's public rules, and when your agreement contains bespoke terms the resulting position is wrong in one direction or the other. Wrong in your favour is more dangerous than wrong against you, because you will not go looking for it.

Problem two: virtualisation multiplies exposure and the rules are contested

The largest audit exposures we see are not caused by people installing software they should not have. They are caused by infrastructure behaving normally. A workload sits in a cluster, the cluster has live migration enabled, and several major vendors take the position that licensing must cover every host the workload could run on rather than the hosts it did run on. That position is contractual and frequently disputed rather than settled, and how it applies to your agreement is a question for your licensing counsel, not for a software product. But your model has to be able to compute the position under both readings, because you will need both numbers: one for your internal risk view and one to understand what the vendor will claim.

Cluster boundaries, affinity rules and whether a host is in a resource pool therefore become licensing controls, and almost nobody treats them that way. The useful thing custom software does here is invert the workflow: instead of reporting exposure after the fact, evaluate proposed infrastructure changes before they happen. Adding four hosts to a cluster becomes a change request that returns a licensing impact alongside the capacity impact. That single feature has prevented more exposure in the organisations we have built it for than any amount of reporting.

The ground is also moving underneath this. VMware's shift to per core subscription licensing under Broadcom changed the arithmetic for a great many estates, and Oracle's Java SE Universal Subscription moved to a per employee metric, which is a fundamentally different counting problem from anything an install based discovery tool was designed for. Neither of those is an edge case. Both are reasons your model needs metrics as configurable logic rather than a fixed set.

Problem three: discovery counts installations, not licensable units

Your discovery estate, whether that is SCCM, Lansweeper, an agent based scanner or a mixture, reports software found on hosts. Licensable units are something else: physical cores with a vendor specific core factor applied, named users with a minimum count per processor, concurrent sessions, devices, employees including contractors, or processor value units. The translation from one to the other is vendor specific and version specific, and it is where the real engineering sits.

It also needs inputs discovery does not always provide: physical socket and core counts underneath a virtual machine, whether hyper threading is enabled, cluster membership, which environments are development or test and therefore covered by different rights, and which users are actually licensed versus merely present in the directory. A build spends much of its effort on this join, pulling from your virtualisation platform, your CMDB, your identity provider and your HR (Human Resources) system, then flagging the hosts where the data is insufficient to compute a position at all. That exception list is one of the more useful outputs, because unknown hosts are exactly where audit findings come from.

Problem four: a position is only useful if it can be reproduced later

An effective licence position is a statement about a moment. If your tooling only shows the current state, then when a vendor asks about a period two years ago you have nothing, and if you have to restate a position after correcting an error you cannot show what changed. Anything built for audit defence has to be point in time reproducible: store the inputs, the rules version and the computed result together, so any historic position can be regenerated exactly with the evidence behind each line.

Treat this as an evidence system rather than a reporting system. Append only records, no silent edits, a visible trail from each computed number back to the discovery record and the contract page that produced it. That property is what makes the difference between a position your counsel is willing to send and a spreadsheet the vendor's auditor will pick apart.

What this costs and how long it takes

A first release covering structured entitlement modelling for your three highest risk vendor agreements, the reconciliation against your existing discovery estate, licensable unit calculation with configurable metrics, and a reproducible point in time position runs $80,000 to $170,000 and ships in 14 to 18 weeks. A full platform adding continuous monitoring with alerting on infrastructure changes, pre change impact modelling, cloud bring your own licence and container coverage, renewal and true up support, and workflow for the audit response itself runs $200,000 to $450,000 over 6 to 12 months.

The cost drivers here are unusual. Contract volume and condition matters most: an organisation with ordering documents scanned as images from the 2000s is looking at a materially bigger discovery effort than one with a tidy contract repository. The number of distinct metrics you have to support is next, since each one is its own calculation with its own edge cases. Whether your virtualisation estate is uniform or a mix of platforms after acquisitions. And how good your CMDB is, because a licensing calculation inherits every inaccuracy in the infrastructure data underneath it, and cleaning that up is often a prerequisite project rather than part of this one.

Build versus buy, and when buying is right

Buy if your estate is predominantly per user subscriptions with straightforward metrics and no significant on premise core based licensing. Snow, Certero or ServiceNow's software asset management module will handle that shape competently, and ServiceNow in particular is the sensible choice if you already run it and your configuration data is accurate, since it inherits both the strengths and the weaknesses of your CMDB.

Our recommendation for large estates is a hybrid, and we give it consistently. Keep the commercial tool for discovery, normalisation and the product recognition library, because rebuilding that catalogue is a decade of unglamorous work with no competitive value to you. Build the entitlement model and the calculation engine for your three to five highest risk agreements, because those are the ones where a generic interpretation is dangerous and where your negotiated terms differ from the vendor's published policy. That split usually costs less than the difference between two years of an expanded tool licence, and it puts the part that carries the exposure under your control.

Build the full picture when you have received an audit letter in the last three years from any major vendor, when a licensing decision is being made implicitly by infrastructure changes nobody reviews, or when your renewal negotiations start from the vendor's numbers because you cannot produce your own with confidence.

How to choose a developer for licence compliance software

Ask how they would compute a position for a database product running in a cluster with live migration enabled. If they do not immediately ask which vendor and which agreement, they are going to encode one interpretation and hand you a number with false confidence.

Ask how a position from eighteen months ago is reproduced. Ask what happens to hosts where the underlying physical core data is unavailable, since the correct behaviour is to raise an exception rather than assume. Ask what they will do with contracts that exist only as scanned images, because the honest answer involves human review and a developer who claims full automation has not defended an audit.

This is also a project where your licensing counsel and your ITAM lead should be in the room during design, not shown the result. The software encodes interpretations that carry legal weight, and those interpretations are not an engineering decision. Settle code and infrastructure ownership before kickoff: repository, cloud accounts and the freedom to bring in another firm. At Digital Heroes the client owns the code from the first commit. A sensible first step is to pick your single highest risk agreement and try to assemble its entitlement record from source documents. However long that takes is your real audit response time, and it is usually the number that decides the project.