A software asset management policy is the short set of rules that decides how software is requested, bought, installed, used and retired in your organization, and who answers for each step. It is the part of SAM that no tool can supply. Without it, licenses arrive through company cards, project budgets and cloud consoles, and nobody sees the gap until a publisher’s auditor does.
Below we explain what a good policy covers, give a template you can adapt section by section, and list the mistakes we see when organizations write their first one. The policy is one step in the wider software asset management process.
In short
- A software asset management policy sets the rules for every stage of a license’s life: request, approval, purchase, deployment, use, renewal and retirement.
- It names an owner for SAM and says who may buy software, who may install it and who answers a publisher’s audit letter.
- Two to four pages is enough. The step-by-step detail belongs in procedures that sit under the policy.
- A policy only works if procurement, the service desk and the cloud teams follow it, so it needs a sponsor on the management team.
What should a software asset management policy cover?
We judge every policy we review against one question: if a publisher audits you tomorrow, does the policy make sure you already hold the records they will ask for? These are the sections that make the answer yes.
| Section | What it decides | Why it matters |
|---|---|---|
| Purpose and scope | Which software, devices, cloud services and group companies it covers | Software bought by a subsidiary or used in the cloud still has to be licensed |
| Roles | Who owns SAM, who approves purchases, who installs software and who answers audits | Without a named owner, nobody keeps the records current |
| Requesting and buying | The only routes by which software and subscriptions may be bought | Purchases outside procurement are where entitlements most often go missing |
| Installing and deploying | Who may install software, on which systems, and how virtual and cloud deployments are approved | For Oracle, Microsoft and IBM, the way software is deployed decides how many licenses it needs |
| Records | What is kept for each license: contract, order, metric, quantity and support dates | These records are your evidence; our guide to software license entitlements lists what to keep |
| Use and changes | Rules for new hardware, moving workloads and switching on options or features | One enabled option or a larger server can turn a surplus into a shortfall |
| Renewal and retirement | How renewals are reviewed, and how unused software is removed or reused | Unused software costs support every year it stays on the renewal |
| Audits and publisher requests | Who receives and answers audit letters, and that nothing is shared without review | The first reply to a publisher shapes the whole audit |
| Breaches | What happens when the policy is not followed | A rule without a consequence is only a suggestion |
Software asset management policy template
Use the wording below as a starting point. Replace the words in brackets, delete what does not apply to you, and keep it short. Each section is written so that someone checking the policy, inside or outside the company, can see whether it is being followed.
- Purpose. This policy sets out how [Company] requests, buys, deploys, uses, records and retires software and cloud subscriptions, so that we use only what we are licensed for and pay only for what we use.
- Scope. It applies to all employees, contractors and companies in the [Company] group, and to all software, whether installed on our devices, run in our data centers or used as a cloud service, however it was paid for.
- Responsibilities. [Role] owns this policy and the software asset management function. [Procurement role] is the only route for buying software. [IT role] approves and records every installation and deployment. Department heads make sure their teams follow this policy.
- Buying software. Software and cloud subscriptions are bought only through [procurement process]. Purchases on expense claims, company cards or cloud marketplaces need approval from [Role] before they are made. Every purchase is recorded with its contract, order document, product, metric, quantity and support or subscription dates.
- Installing and deploying. Only [IT role] installs server software or changes how it is deployed. Users install only software from [approved catalog]. Moving software to new hardware, a virtual cluster or a cloud service needs approval from [Role] first, because it can change the number of licenses required.
- Records. [Role] keeps a current register of what we are entitled to use and what we have deployed, and reconciles the two at least [every quarter] and before every renewal and audit.
- Renewals and retirement. Renewals are reviewed [90 days] before they are due. Software not used for [90 days] is removed or reassigned. No license is dropped from support until [Role] has reviewed the publisher’s terms.
- Publisher audits and requests. Any letter, email or call from a software publisher about license use goes to [Role] on the day it arrives. Nobody shares data, runs a publisher’s script or signs a document without approval from [Role].
- Breaches. Software bought or installed outside this policy will be removed or brought into compliance, and the cost may be charged to the department responsible.
- Review. This policy is reviewed every [12 months], and after any merger, acquisition or major change in how we use software.
Is a software license management policy the same thing?
Not quite. A software license management policy is usually narrower: it covers compliance with license terms and the records that prove it. A software asset management policy also covers how software is bought, what it costs and how it is retired. In most organizations the license management rules are sections 4 to 8 of the template above, so one document is enough.
How do you put the policy to work?
- Agree a sponsor on the management team, ideally the CIO or CFO, and an owner who has the time to run SAM.
- Build the rules into the systems people already use: the procurement system, the service desk catalog and the approval steps for new servers and cloud accounts.
- Record what you own and what you run, and reconcile the two into an effective license position for each major publisher.
- Report a few measures each quarter, such as unapproved purchases found, software removed and the license position for your largest publishers.
This is the discipline our software asset management services run for clients all year: we discover what is deployed, reconcile it against what you own and report against your cost and risk targets. We take no fees, commissions or partnerships from any software vendor, so the advice is about your position, not a publisher’s sales target.
Mistakes we see in SAM policies
- It is too long to be read. A thirty-page policy gets filed, not followed. Keep the rules in the policy and the detail in procedures.
- Nobody owns it. When the owner is “IT”, in practice it is no one.
- Cloud and SaaS are left out. A subscription bought by a team on a company card is a software purchase too.
- It does not say who answers an audit letter. When a publisher’s letter reaches the wrong person, data can be shared before anyone with licensing knowledge has seen it. Our software audit checklist covers what to do in the first 30 days after a letter arrives.
- Support is dropped without checking the terms. With some publishers, Oracle among them, ending support on part of a set of licenses can change what you pay for the rest. Our article on shelfware explains how to remove unused licenses safely.
Questions we are asked about software asset management policies
Who should own the software asset management policy?
A named person with authority over software spending, usually the head of IT asset management or IT procurement, with a sponsor on the management team. Ownership by a committee or a whole department rarely works.
Do we need a separate policy for SaaS and cloud?
No. Cover cloud subscriptions in the same policy, with a rule that every subscription is bought through the approved route and recorded like any other license. Two separate policies tend to leave gaps between them.
How long should a SAM policy be?
Two to four pages. If yours is longer, move the step-by-step detail into procedures and keep the policy to rules and responsibilities.
Where do we start if we have no policy today?
With three rules: who owns SAM, the one route for buying software, and who answers a publisher’s letter. Those are sections 3, 4 and 8 of the template. Add the rest once those three are being followed.
Anil Nahata
Co-founder of Rythium Technologies and its designated partner since 2015. Anil co-leads Rythium’s practice, bringing deep software asset management and commercial negotiation experience across Oracle, Microsoft and the wider publisher landscape.
Before Rythium, Vice President heading the telecom towers infrastructure business at Reliance Communications, and its group Chief Procurement Officer. More than two decades across the telecom, software and financial industries.
See more of our analysis in Google: add Rythium as a preferred source