Business software & SaaS purchasing

Buying software became an operating process

When software was bought outright, not deciding meant not spending. Subscription licensing inverted that: not deciding means paying again, on the same or a higher schedule, and the portfolio grows by default unless somebody retires things. That is why software now behaves like a facility cost rather than a capital purchase, and why it needs the apparatus a facility has — a named owner, a calendar of decisions, and a standing rule that nothing renews without a person confirming it is still worth holding.

• The default outcome of doing nothing is another term.
• Portfolios grow unless somebody retires things.
• One named owner for the whole portfolio.
• Nothing renews without a confirmation from that owner.

Inventory first: what you actually hold

You cannot negotiate a portfolio you cannot list, and the list is harder to build than it sounds because subscriptions get bought on cards, bundled inside other tools, and by teams that have since changed hands. Build one row per subscription with a named business owner, the licences purchased, the people who actually signed in during the last quarter, the renewal date, the notice period, whether it renews automatically, which identity system it uses and who pays. Discovery does not have to be manual either: software identification tags, the standard NIST calls SWID and publishes implementation guidance for, are what inventory tooling reads to identify what is installed, so the reconciliation can start from the systems rather than from a spreadsheet somebody maintains.

• One row per subscription, with a named business owner.
• Licences purchased against people who signed in last quarter.
• Renewal date, notice period and whether it renews itself.
• Discovery reads installed software identification tags, not a maintained list.

The renewal calendar is the tool that changes outcomes

Almost every commercial lever sits in the window before renewal, and that window is shorter than people expect because notice periods are written to run before the term ends. Put every renewal on a calendar keyed to the notice deadline rather than the end date, working back from each one. Stagger the portfolio deliberately so decisions do not all land in the same month, and mark which subscriptions share a vendor, because consolidation is a lever only if the renewal dates can be aligned without paying to break terms.

• Calendar the notice deadline, not just the end date.
• Stagger renewals so the decisions do not cluster.
• Mark which subscriptions share a vendor and could be pooled.
• Open each decision before its notice window, not during it.

Identity and access before features

Every subscription is an identity integration, and the ones outside the central identity system are the ones that survive a departure. NIST's account management control, AC-2 in SP 800-53 Revision 5, treats the account itself as the thing with a lifecycle — created, modified, reviewed, disabled and removed — which is precisely the discipline a subscription portfolio needs. The practical mechanism is assignment through a group rather than one licence at a time: Microsoft documents group-based licence assignment in Entra, where adding a person to the group grants the licence and removing them returns it. A product that cannot work that way is a decision to manage access by hand forever.

• Single sign-on required for anything holding business data.
• Multifactor authentication as the baseline, not an upgrade.
• Licences assigned through groups, so removal is automatic.
• Administrative roles separated from everyday user accounts.

What to ask a vendor about how the software is built

Buying software is also buying the vendor's development process, and that is now something you can ask about in writing. NIST SP 800-218, the Secure Software Development Framework, sets out secure development practices and tasks that a supplier can be required to follow, which turns a vague request for good security into a checkable one and lets a buyer compare two vendors on a common basis. The companion question is provenance: whether the product can supply a list of the components inside it, because when a widely used library turns out to be compromised that list is what tells a buyer whether they are affected, and how quickly they can know. Ask how that list is kept current, not only whether one exists.

• Ask which development practices the vendor follows, and for evidence of them.
• Reference NIST SP 800-218 rather than a general assurance claim.
• Ask for the component inventory inside the product, and its update path.
• Make patch and vulnerability notification a contractual obligation.

Seats, tiers and what changing them really involves

Licence models differ in ways that matter operationally. Named-user licensing charges per person whether or not they use it, which makes an accurate active-user count the most valuable number you hold. Concurrent licensing charges for simultaneous use and suits staggered shifts but fails when everyone works at once. Usage-based licensing moves the risk to you and needs monitoring so a busy month does not arrive as a surprise. In enterprise agreements the same logic appears as a true-up, a periodic reconciliation of actual usage against purchased licences so the count can be corrected for compliance — which is why an inaccurate inventory is a commercial exposure rather than an administrative one. Tier changes are not symmetrical either: moving up is usually immediate, while moving down can be restricted by the term, and features that hold data may not survive the downgrade.

• Named, concurrent or usage-based, and which fits the working pattern.
• Active users, not purchased seats, as the number that matters.
• Whether a downgrade is permitted mid-term.
• Which data survives a downgrade, and which does not.

What to gather before asking for pricing

Bring the inventory with owners, seats, renewal dates and notice periods, an active-user count per product, the integrations that must keep working, any obligation that constrains where data may be held or how long it is kept, the identity standard the business requires, and the date by which any change has to be complete. If consolidation is the goal, say which products are candidates and which are not. A request that states the constraint gets a more useful answer than one asking for the best option, and it is the difference between a comparison you can act on and a demonstration you cannot.

• Inventory with owners, seats, renewal dates and notice periods.
• Active-user counts, per product.
• Integrations, identity requirements and any data obligation.
• Which products are consolidation candidates, and which are not.

A true-up reconciles use against entitlement; an audit checks the record

An enterprise agreement usually carries two separate mechanisms, and they answer different questions. The true-up is the reconciliation the customer performs: Microsoft's Enterprise Agreement guidance describes an annual true-up in which the customer inventories the products, services, users and devices added over the preceding twelve months and reports the resulting quantity, with the true-up order falling due between sixty and thirty days before the enrollment anniversary and the renewal order about thirty days before the term ends. A true-up is not a downward adjustment — reductions are handled at renewal — which is why an accurate active count taken early is worth more than an argument made late. The verification clause is the other mechanism: read it for the notice it requires, how often it may be exercised, what it may cover, the method permitted, how a shortfall is measured, and the period allowed to cure one. An enterprise agreement also carries a minimum, so a small estate may fall outside this structure altogether. The obligation itself lives in the licence terms and order documents, not in the audit clause.

• The true-up is the reconciliation you perform; the verification clause is the vendor's right to check it.
• The true-up captures additions over the preceding twelve months and is not a downward adjustment.
• Read the verification clause for notice, frequency, scope, method and the cure period.
• The obligation is set by the licence terms and order documents, not by the audit clause.

Reclamation is what changes a renewal baseline

The quantity that decides a renewal is the active one, and getting to it means separating four numbers per product: purchased, assigned, enabled and active. Shelfware is entitlement that is paid for but not assigned, or assigned and not used, and the measurement window matters — a ninety-day inactivity test overstates waste for a seasonal or occasional role, while a thirty-day test understates it. The mechanics are ordinary housekeeping: reclaim a licence when a person leaves or changes role, remove duplicate assignments, review guest, contractor and shared accounts separately, compare the vendor's admin-centre assignment data against your identity provider and HR records, and reassign a reclaimed licence before buying another. Keep an exception list for the people who need access despite low recent activity, so the reclamation is defensible. The record structure for that work is what ISO/IEC 19770-1 sets out as an IT asset management system, and reclamation does not reduce a current-term commitment — it produces the evidence that sets the next one.

• Four numbers per product: purchased, assigned, enabled and active.
• Match the inactivity window to the role, not to the calendar.
• Reclaim on role change and departure; reassign before repurchasing.
• Compare vendor assignment data with identity and HR records.
• Reclamation sets the next commitment, not the current term.

Four renewal dates, and the pricing clauses to separate

Renewal is not one date. There is the true-up order, due sixty to thirty days before the enrollment anniversary; the renewal order, which the vendor advises submitting about thirty days before the term ends; the notice deadline written into the agreement itself, which is the only date that governs whether a renewal can be stopped; and the preparation window, which is practice rather than contract and wants to open several months out so usage analysis and alternatives are done before the notice window closes. Pricing has its own four concepts to keep apart: a price lock fixes the unit price for a period, price protection sets the basis on which additions are priced, an uplift cap puts an express ceiling on an increase, and renewal repricing lets the vendor reset at renewal. Those are negotiated terms rather than defaults, and the same discipline applies to the automatic-renewal statutes in some states: they are drafted around consumer transactions, so do not assume a statutory backstop. The agreement's own notice clause is what a business has to comply with.

• True-up order, renewal order, contractual notice deadline, preparation window.
• The notice deadline is the date that decides whether renewal stops.
• Separate price lock, price protection, uplift cap and renewal repricing.
• Do not assume a statutory backstop; the agreement's notice clause governs.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions