Software access review: how a usage report becomes a keep-or-release decision

The quarterly access review has all the numbers on the screen. Seats bought per application. Last sign-in per person. A column of names who have not opened the tool in ninety days.

Then the meeting ends and nothing changes. The seats renew, because nobody in the room was authorised to release them, the people holding them were never asked, and the next review has no owner.

A software access review is a decision about each paid seat — keep, release or reassign — made by someone with the authority to act, informed by the person who holds the seat, and scheduled to happen again. Usage data is the evidence for that decision. It is not the decision.

What is a software licence access review supposed to decide?

It decides, for each paid seat, whether the person holding it still needs it for their work, and what happens to it if not.

That is a different question from a security access review. Security asks whether this person should be able to reach this system. A licence review asks whether this seat earns its cost in this person’s work. The list of names is the same, so many teams run the first review and assume it has covered the second.

Why doesn’t a usage report produce the decision on its own?

A usage report shows activity; it cannot show why a seat is idle.

Someone who has not signed in for three months may have changed role. They may use the tool twice a year for one specific task, such as a year-end reconciliation. Or they may never have been shown how the tool fits their work. Those three answers lead to three different actions — release, keep, enable — and the dashboard shows all three people as the same grey row.

The gap is not limited to licences. In KPMG’s Q3 2026 global AI pulse survey of 2,131 senior leaders across 20 countries, 61% review AI costs during approval and 59% monitor them in operation, but only 12% consistently assess AI value against cost across the organisation. Monitoring cost is common. Connecting it to what the work produced is rare. A licence dashboard has exactly the same limit. _(KPMG sells AI advisory services, and the survey is global rather than CZ/SK-specific.)_

What does the review need to contain?

Four objects, each attached to a specific application:

1. Usage against licence count. Seats bought, seats assigned, seats used in the review window — and a written definition of “used”. A sign-in is weak evidence; a meaningful action in the tool is better.
2. The seat holder’s answer. A short check sent to the person holding the seat: do you still need it, for which task, and how often? Give it a stated default — for example, no answer within two weeks means the seat is proposed for release — so that silence does not quietly mean keep.
3. The owner of the decision. A named role per application who may release or reassign seats and who owns the renewal date. If nobody in the review can act, the review can only report.
4. The next review. A date, a cadence that matches the cost of the tool, and the events that trigger an earlier look: a renewal, a role change, a team move.

A buyer described the same list before we did

In an r/ITManagers thread from February 2025, one IT manager listed what he wanted from a software lifecycle and access-review process: to see “utilization of the app against my license count”, to let employees see the software available and request a seat, to notify people who had not signed in, and to ask whether a seat still made sense for them.

He had already built this himself and described maintaining it as painful, and the packaged tools he looked at bundled far more than he needed. That is one person’s wishlist, not a benchmark. It still maps almost one-to-one onto the four objects above, and it points at the part that tools tend to leave out: somebody has to run the conversation with the seat holder and make the call.

Where does the time go in a manual access review?

Most of the time goes into assembly, not judgement.

Someone exports usage from several admin consoles, reconciles names that are spelled differently in each, emails managers to ask about their people, waits, chases, records the answers somewhere, and then repeats the whole exercise next quarter. The decision itself takes minutes. The collection takes days, which is why a review that is painful to run is usually the review that quietly stops happening.

That makes the review a workflow worth designing: one source for usage, one employee-facing question, one place where the decision and its owner are recorded, and one date for the next pass.

What changes when the decision is designed into the review?

Every seat leaves the review with one of three outcomes and a name next to it.

• Release — and the renewal quantity is adjusted before the renewal date, not after.
• Keep — with the task the seat serves written down, so the next review does not ask the same question from scratch.
• Enable — the person needs the tool but has not been shown how it fits their work. That becomes an enablement item, not a cancellation.

The third outcome is the one a pure cost review misses. An idle seat is not always waste. Sometimes it is capability the company already pays for and nobody has connected to the work.

How does the AI Workflow Audit use this?

In the AI Workflow Audit, the Workflow & Usage Report is built around these decision objects rather than around a single total: usage against licence count, what the people holding the seats tell us about their work, what to release, what to keep, where the gap is enablement, and who owns the next review.

Licence savings are one possible finding; we do not assume waste before we have looked. We are also vendor-neutral, so “cancel this tool” is an answer we are free to give — and “keep it, and show the team how it fits the task” is an answer we are equally free to give.

A usage report tells you where to look. The review is where someone with authority decides, and the design of that review is what makes the decision happen every quarter instead of once.