Implementing SAM Policies and Procedures

Depending on how long it took to inventory your software and match it to your licences, you will reach a point where the immediate job is done and the real one starts. Cleaning up a licence position is a project. Keeping it clean is a set of policies.

Without them the position decays at a predictable rate, because the behaviours that created the mess in the first place are still running. Below are the four policies worth writing, and two more that did not exist when this post was first published.

Software acquisition

If departments and individuals have been buying software independently, two things follow. You are missing volume discounts you could have had, and you cannot state what you own, because the purchase records are scattered across expense claims, departmental budgets and people’s inboxes.

A centralised procurement route fixes both. Every acquisition passes through one process, is recorded against one entitlement store, and is checked against what you already hold before anything new is bought — because a surprising share of “we need to buy this” turns out to be “somebody already did.”

The policy is easy to write. The difficulty is that a centralised route is slower than a corporate card, so it only holds if the sanctioned path is fast enough to be worth using. Which is why this policy and the next one have to be designed together.

Software use

An inventory almost always turns up software nobody knew was installed. That is a security exposure and a licensing exposure at once: an unpatched application nobody is tracking, on a machine nobody assigned it to, consuming an entitlement nobody bought.

A software use policy addresses this with an approval process for new installations, so that what is deployed stays known.

The version of this policy that works is not a document. It is a request route that is faster than working around it, paired with enforcement that makes the workaround fail.

Both parts ship:

• App-Centre, a self-service portal with manager approval chains, backed by software distribution for MSI, EXE and Click-to-Run packages. A request that is approved is installed, from a controlled source, against a record. That is the fast path.
• Application blacklisting and prohibition rules, with a Blocked Files log recording per-user and per-device block counts. That is the enforcement — and the log is more useful than the blocking, because a title being blocked repeatedly by the same team is a statement of unmet demand, not a discipline problem.
• Governance Policies, which work as compliance-as-code over a reusable filter builder, with definitions that export and import as JSON. A standard expressed this way is a check that runs continuously, not a page in a policy pack.

Intake: recording what arrives

To keep the inventory current, define the documented steps that follow every new acquisition.

The original version of this post said to store the bill of lading, the original packaging and the media. That is no longer the entitlement chain for most organisations, and following it literally today would leave you with nothing. The modern equivalent is the same discipline applied to digital records:

• The licence statement or entitlement record from the publisher — for Microsoft, the Microsoft Licence Statement, which CerteroX SAM imports directly.
• The order confirmation, purchase order and invoice, captured against the transaction rather than filed in finance alone.
• The agreement itself, with its maintenance terms, supplier, publisher and renewal dates.
• The transaction type — volume licence, retail, OEM or FPP — because the type determines what the installation is permitted to be, and it is not recoverable later from the deployment data.
• Subscription flags and expiry dates, so a subscription that lapses is visible before it lapses.

Held together, these are what an effective licence position is computed from: purchased, used, available, required, variance and exposure. Held apart, they are what people spend three weeks assembling when an audit letter arrives.

Disaster recovery

Make sure the organisation’s disaster recovery plan has a section on recovering software after a catastrophe.

Two things belong in it. The first is the obvious one: your entitlement records need to survive whatever took out the systems they describe, or you will be reinstalling software you cannot prove you own.

The second is less obvious and more expensive. Disaster recovery and failover environments have licensing consequences of their own, and the treatment of cold standby, warm standby and active-active differs by publisher and often by agreement. Check what your specific agreements permit before the DR environment is built, rather than after it has been running warm for two years.

The policy the original list predates: SaaS purchasing

Everything above assumes acquisition means procurement. It largely does not any more.

The average enterprise portfolio now runs 305 SaaS applications. Very little of that arrived through a purchase order. A SaaS application needs no server, no installer and no approval — only a card and an email address — which means the acquisition policy above has no point at which to intervene.

The control that works here is discovery rather than gatekeeping. CerteroX SaaS Management uses three converging signals: a browser extension detecting application domains, time-on-app and per-user attribution; identity provider sync from Entra ID and Okta; and connector sync pulling authoritative user and licence lists from the vendors themselves. Applications are classified against a catalogue of over 35,000, and 47 connectors ship today.

Once things are visible, the policy has something to act on: four owner types per application — application, business, technical and data owner — so every application has somebody accountable; per-application budgets with warning and critical thresholds; and a risk assessment covering data sensitivity, compliance and business criticality.

The other one: leavers

The original list has no offboarding policy, and in 2016 it did not badly need one. Removing someone’s Windows account largely removed their access.

It does not now. 46% of SaaS licences go entirely unused — the average organisation uses 54% of what it pays for — and a meaningful part of that is seats still assigned to people who left. The directory account is disabled on day one. The Figma seat, the Notion licence and the OAuth grant that still has read access to the company drive are not.

The policy is a completion requirement rather than an instruction: offboarding is not finished when the account is disabled, it is finished when every licence is revoked and every grant is withdrawn. What makes that enforceable:

• A per-user offboarding checklist showing every licence held, the connector status behind each one, and whether revocation is pending, in progress or complete — with the estimated monthly cost of whatever is still open.
• A workflow engine with eight triggers, eleven conditions and thirteen actions on one canvas, covering provisioning and deprovisioning across Entra, Okta, Google and Microsoft 365 among others.
• OAuth grant discovery and risk scoring on data sensitivity, scope, consent and dormancy, with one-click revocation that is also available as a workflow action.
• An audit log covering every provisioning and deprovisioning step, which is what turns “we have an offboarding process” into something you can hand to an auditor.

Making the policies stick

Four things separate a policy set that survives its first year from one that does not.

Give each policy an owner and a check. A policy without a scheduled check is an opinion. Governance Policies, threshold alerts and scheduled reporting agents exist so that drift raises a flag rather than accumulating quietly.

Restrict visibility rather than trust. Reporting Levels enforce visibility by organisational unit or location, Zones segment data across entities, and role-based access control handles the rest. Devolving SAM responsibility works only when devolved people can see their own scope and no more.

Keep the audit trail as you go. Agreements, transactions and exclusions should carry their history by default. Reconstructing intent two years later is the single most expensive activity in software asset management.

Sequence the policies against where the money leaks now. For most organisations that is SaaS purchasing and leaver recovery, not media storage. Write the four classic policies, then check that they still describe how your organisation actually acquires software.

Book a demo, or read more about CerteroX SAM and CerteroX SaaS Management.