ServiceNow software asset compliance workflows with usable evidence

What a vendor audit request usually asks for

A software audit notice rarely asks for everything at once. It usually asks for a defined set of products, a period and a list of the places where those products were installed or used. The requesting party will compare what it receives with what it holds. An organization that has to assemble that evidence under time pressure will normally find that its records disagree with each other, and the audit becomes a reconciliation carried out in public. The same work done before a renewal or an audit notice is slower in the calendar but far cheaper in consequence.

This section is for the software asset manager or procurement lead who is preparing for either a renewal or a notice, and who needs to decide whether to reconcile now. It describes the evidence the work produces, where it usually breaks, and what a defensible position looks like without claiming that any particular position is guaranteed. The records that feed it relate to the CMDB, CSDM and ITAM page, which covers configuration, service and asset data.

The table is a checklist for the reviewer, not a description of how any vendor counts. Each vendor defines its metrics and its rights in its own terms, and those terms should be read from the agreements that the organization holds rather than assumed from general practice.

Reconciling before the renewal date, not during the notice

The renewal date is the natural moment to reconcile, because the commercial team is already looking at the product, the budget owner is already involved and the cost of changing the position is still low. A reconciliation started after a notice arrives has a different character. The timetable is set by someone else, the questions are framed around the requesting party’s metrics and every discrepancy becomes a point of negotiation.

1. Pick the products with the largest commitment or the most complicated rights first, not the ones that are easiest to list.
2. Reconcile entitlement against the agreement itself, including amendments, rather than against the summary in the register.
3. Reconcile deployment against at least two sources where possible, and note which devices or accounts neither source can reach.
4. Agree with the product owner which unexplained installations are in use, retired or unauthorized, and record the answer.
5. Write the position as a dated statement that the commercial owner can sign, so the organization has one account of where it stands.

The last step is easy to skip and expensive to omit. A reconciliation that exists only in a working spreadsheet cannot be defended in a renewal conversation, and it cannot be handed to a new commercial owner when the person who built it moves on.

Product names, editions and the same software under different labels

Much of the difficulty in software reconciliation is naming. The same product may be recorded under a trade name, a vendor product code, an edition, and an installer name that includes a version number. A discovery run can record each of these as a separate product, which makes the total appear larger or smaller than it is. The reconciliation has to decide which records describe the same entitlement, and that decision should be written down because it affects the result. Where the same product appears as several configuration records, the CMDB reconciliation and duplicate control page deals with identity, source precedence and duplicate review.

Editions are the other source of trouble. A deployment may show a product that is technically installed but is an edition the organization is not licensed to run, or a lower edition that carries a different set of rights. Matching edition to entitlement requires the person reviewing the record to read the rights description rather than the product title, and that reading is a judgment which should be recorded with the reviewer’s name.

The software model reference describes how product records are structured, and the software entitlement reference covers how the commercial side is represented. The reconciliation needs both, and the work is in the links between them.

Deployment that cannot be seen

Every reconciliation has a population of installations that discovery cannot see: devices off the network, hosted services accessed through a browser, software embedded in another product, and accounts created outside the normal process. The position is only as defensible as the organization’s honesty about those gaps. A statement that says the population is complete when it is not will be tested by the requesting party, and the consequences are worse than an accurate statement of limits.

The better approach is to list the unseen population explicitly, estimate it from the sources that exist, such as procurement records for devices or account lists for hosted services, and say which items were verified and which were inferred. An inferred figure is useful for planning, but it should not be presented as a count.

Who signs the compliance position

A compliance position is a statement about the organization, and it needs an accountable signatory. In practice that is usually the commercial owner, supported by the software asset manager and the technical owner for the products concerned. The signatory should not be the person who built the reconciliation, because a second reader catches the assumptions the builder has stopped seeing. The signatory should also know which exceptions have been accepted and why.

Exceptions deserve a line of their own in the statement. A product that is installed without an entitlement, or an entitlement with no installation, should be listed with its disposition: corrected, purchased, removed, accepted or still under investigation. A list of exceptions with dispositions is more credible than a statement that says all products are compliant.

What a clean position does not guarantee

A reconciliation that reaches a clean position on the day it is completed will not stay clean. New installations appear, contracts change, teams reorganize and products are renamed. The value of the work lies in the process that keeps the record current and in the evidence it leaves for the next review. It does not lie in a single figure, and it does not protect the organization from a dispute about how a vendor interprets its own rights. Where a dispute arises, the reconciliation makes the organization’s own account clear, which is the basis for a sensible response.

Questions to settle before a renewal or notice

Should reconciliation wait for the vendor to ask

No. Reconciling before the notice is usually cheaper and calmer, and it tends to produce a better record. Waiting converts a planning task into a response under deadline, and the response is usually built on the weakest of the available sources.

How far back should the reconciliation look

Far enough to cover the period the agreement or the notice describes, and to explain any change in the installed base across it. The period should be agreed with the commercial owner, because it determines which records must be retrieved and how much evidence must be preserved.

What evidence should be kept with the position

Keep the agreements and amendments that were read, the source extracts used for deployment, the list of unseen populations and the signed exceptions. Without those, the position cannot be re-tested by someone who did not do the work.

What should a buyer ask a provider about software compliance work

Ask how the provider separates entitlement from deployment, how it handles naming and edition matching, how it records the unseen population and who signs the result.

Next step for a software compliance review

Bring the agreements, the deployment extracts and the list of exceptions to a conversation about the reconciliation approach and about how the result will be signed.