ServiceNow Software Asset Management Professional Governance Model

Defining the Governance Structure

Software Asset Management (SAM) involves tracking licenses, managing compliance, controlling costs, and maintaining relationships with vendors. Governance ensures SAM operates consistently and delivers value. Establish a governance structure: a SAM steering committee (usually including IT, finance, legal, procurement) meets quarterly to review software asset status, approve licensing decisions, and oversee cost management. A SAM operations team (usually within IT) manages day-to-day SAM activities: tracking licenses, managing renewals, conducting audits.

The steering committee sets policy; the operations team executes it. Clear governance prevents inconsistent decisions: some teams negotiate aggressive licensing terms while others overpay for unnecessary software.

License Management and Compliance Controls

Establish standards for software procurement and licensing. Which software can teams purchase, who approves purchases, what licensing terms are acceptable? Implement a control: software can only be purchased through a centralised procurement process that includes a license review. This prevents teams from buying software without understanding license terms and avoids duplicate purchases.

Track licenses meticulously: for each software product, maintain a record of the license agreement, the number of licenses purchased, the number currently in use, and when the license expires. Reconcile this data regularly: are we using fewer licenses than we paid for (waste), or more than we purchased (compliance risk)? Use this reconciliation to optimize spending: if we are using only half of purchased licenses, reduce the next purchase.

Vendor Relationship Management

Large software vendors (Microsoft, Adobe, Salesforce, ServiceNow) are key business partners. Manage these relationships proactively. For each significant vendor, designate a relationship owner (usually in IT or procurement). The owner maintains regular communication with the vendor, negotiates terms, and ensures both parties are meeting obligations.

Use ServiceNow to track vendor relationships: who is the vendor contact, what products do we license, what are the license terms, when does the contract renew, what is the total annual spend? This centralised tracking ensures no one person is solely responsible for vendor relationships and makes it visible to leadership.

Software Audit and Reconciliation

Conduct regular software audits: check installed software on devices against your license inventory. If a device has software that is not in your license list, either a license is missing from your records or the software should be removed. Reconciliation often reveals gaps: software installed that is not licensed, or licenses purchased but not deployed.

Work with IT operations to inventory installed software using discovery tools or endpoint management systems. Feed this data into ServiceNow and compare to licenses. Discrepancies become action items: purchase missing licenses, remove unlicensed software, or reallocate licenses to match actual usage.

Cost Optimization and Spending Control

Software spending is often the largest discretionary IT expense. Governance should focus on cost optimisation. Review spending quarterly: which products cost the most, which teams spend the most, where are opportunities to reduce cost? Possible opportunities: consolidate on fewer vendors (bulk discounts), negotiate volume discounts, eliminate duplicate tools (multiple teams buying different products for similar purposes), or find cheaper alternatives.

Implement spending controls: a budget for software spending per team, approval gates for purchases above a threshold, requirements to justify new software purchases (why is this better than what we have). These controls prevent runaway spending.

Policy and Standards Definition

Define standards for software licensing and usage. For example: open-source software requires legal review for license compatibility before use; SaaS purchases must include a security assessment; Microsoft licensing must follow enterprise agreement terms, not individual subscriptions. These standards prevent teams from making uninformed choices that create compliance or security risk.

Document policies in a SAM handbook: which software is approved, which is prohibited, how to request new software, what the approval process is, what happens if someone installs unlicensed software. Publish this handbook to all teams and train new employees on SAM policies.

Remediation of License Non-Compliance

When an audit reveals compliance issues (more software deployed than licensed, unlicensed software in use), develop a remediation plan. Work with the team responsible for the non-compliance: understand how it happened, explain the licensing terms and compliance obligation, and define corrective actions (purchase additional licenses, remove software, or reallocate licenses). Document the remediation: when the issue was discovered, what the corrective action was, when it was completed. This creates evidence for audit.

Governance models should be documented and communicated to all stakeholders. Ensure roles, responsibilities, escalation paths, and decision criteria are clearly defined. Regular review of governance effectiveness helps organizations adapt their model as business needs change. Governance should support both control and agility, enabling efficient decision-making while maintaining necessary oversight.

Why an exception register matters more than the committee chart

Many SAM governance documents describe who sits on the steering group and how often it meets. That is necessary, but it does not stop the problem that often causes trouble: a team installs something it should not have, a manager approves an exception in a hallway, and six months later nobody can say whether the exception still applies. The governance model that holds up under an audit is one that records every licensing exception in a single place, with the reason, the approver, the expiry and the evidence, and that treats an exception without those fields as an open defect rather than a small favor.

For the SAM lead writing the charter, this means the first governance artifact to design is the exception register, not the committee terms of reference. The committee then becomes the body that reviews the register, rather than the place where decisions quietly happen.

Decision classes and who holds each one

Not every licensing decision deserves the same level of authority. Routing a small renewal through the steering group wastes its time and slows the business. Letting a large true-up be approved by the person who discovered it creates the opposite risk. The thresholds belong to your finance function and should be written into the charter as explicit values, not left to judgment on the day.

Running an exception from request to closure

An exception is only useful if it ends. The ordered steps below describe the lifecycle the register should enforce. Each step should be a field that must be completed before the next one is allowed, so that the register cannot be used to approve something and then forget it. Teams that already run a recurring SAM routine can attach the register review to it.

1. Record the request with the product, the install or planned install, the affected devices or users, and the business reason in the requester’s words.
2. Have the licensing lead confirm the actual licensing position from the entitlement records, not from the requester’s understanding of it.
3. Decide the class and the approver. Reject the request if it cannot be classed.
4. Set an expiry date. An exception with no expiry is a permanent change in policy and must be recorded as one.
5. State the remediation: a purchase, a removal, a reassignment, or a documented right the organization already holds.
6. Review the register before each steering meeting and close every exception that has passed its expiry without a documented outcome.

The final step is where many registers fail. Exceptions are approved readily and reviewed rarely, so the register fills with entries that were correct when written and are now simply stale.

Escalation criteria that are not left to judgment

Escalation works best when the criteria are written down and easy to apply. A useful test is whether a person outside the SAM team could decide whether to escalate using only the register entry. If they could not, the entry is missing information. Typical escalation triggers include an exception that has passed its expiry, a discovered install with no entitlement at all, a vendor audit notice, a dispute over whether a right exists, and any case where the requester and the licensing lead disagree about the position.

Write the thresholds for escalation into the charter and make the platform report them. A governance model that depends on people remembering to escalate will miss the cases that matter most, which are often the ones nobody wanted to raise.

Where governance often breaks down

A common breakdown is a split between the people who approve purchases and the people who track installations. Procurement sees a contract signed. The operations team sees software deployed. Neither sees the other’s record, so the gap between them is discovered only at reconciliation. Joining the two through a shared identifier for the product and the agreement is a governance decision as much as a technical one, and it should be assigned to a named owner.

A second breakdown is governance that exists on paper but is not reflected in the platform’s access rules. If the charter says only the licensing lead may change an entitlement, but several administrators can edit it, the charter is not being followed, and the audit trail will show it. The access design needs to enforce the decision rights the charter sets out.

A third is the policy that nobody can enforce because it was written for a different estate. Policies about approved software should be tested against the current catalog before they are published, not after the first incident.

Common questions about SAM governance

Should the steering group approve routine renewals?

Often not. Its time is better spent on decisions that change policy or carry significant financial exposure. Routine renewals should be delegated with a clear value limit, and the steering group should see a summary of what was renewed under that delegation at each meeting.

How do we govern software that business units buy with their own cards?

Treat it as an intake problem rather than a policy problem. The register should capture any product found in the estate without a purchase record, whoever bought it, and the decision should follow the same classes as anything bought centrally.

What evidence does a reviewer expect to see for an exception?

The requester’s reason, the licensing lead’s confirmed position, the approver and the date, the expiry, the planned remediation, and the record of what happened at expiry. An exception that cannot show its ending is treated as an unresolved finding.

How often should the charter itself be reviewed?

Review it when the organization changes its purchasing structure, when a major agreement is renewed on different terms, or when the register shows the same type of exception recurring. A charter that is only reviewed when something breaks is already behind.

Questions about SAM governance

The platform governance charter guidance covers what a charter sets out, namely decision rights, boundaries and review responsibilities.