Approved Today, Assumed Forever: Put a Review Date on Every Tool

Most software approvals are born in a burst of activity. Someone fills in a form, a security questionnaire gets answered, a manager says yes in a chat thread, and the tool is marked as approved. Then everyone moves on. The entry sits in a spreadsheet or wiki for months, quietly ageing like a sandwich in a hot office.

The problem is not that the original decision was wrong. It is that approval is a snapshot of a moment: that tool, that price, that data flow, that team, that owner. Software changes. Companies change. People leave. A tick that made sense eighteen months ago can become an assumption nobody has checked since.

For small UK teams without a procurement department, the answer is not a heavier process. It is a lighter one with a date attached.

Approval is a decision, not a permanent state

An approved tool is not a listed building. It does not become more trustworthy simply because it has been on the list for a long time. It may have added an AI feature, shifted its subprocessors, changed its pricing tiers, or quietly become the place where your team stores client documents.

The approval should therefore carry a review-by date. That does not mean the tool is banned when the date arrives. It means someone has to look again and decide: keep, keep with conditions, replace, or retire. The decision can take twenty minutes. The absence of a decision can cost far more.

One field does most of the work

If you already keep a software register, add a review-by date column. If you do not have a register, start with the tools that handle personal data, payments, customer communications or access to your main systems. You do not need to catalogue every browser extension.

A sensible default is twelve months for most business tools. Consider six months for anything holding sensitive customer data, approving payments, or sitting close to your identity provider. Low-risk utilities can stretch to eighteen months. The exact interval matters less than the habit of setting one.

The second field is the owner. Not the person who signed the contract, necessarily, but the person who would notice if the tool disappeared tomorrow. If that name is blank, the approval has no one to answer for it.

Four triggers that should bring the date forward

A calendar reminder is useful, but it should not be the only alarm. Bring the review forward when one of these things happens.

The owner changes

If the person named on the approval leaves, changes role or goes on long-term leave, the tool needs a new owner. The incoming owner should either accept the approval or schedule a review. An orphaned tool is not approved; it is merely still running.

The price or licence terms shift

A renewal quote with new seat minimums, a fresh add-on tier or a jump in unit price is a review trigger. So is a move from monthly to annual billing. The question is not only whether you can afford it, but whether the new terms still match how the team actually uses the product.

The security or data flow changes

New integrations, new admin permissions, a new subprocessor, a change in data residency, or a feature that sends data to a third-party model are all reasons to look again. You do not need to reread the entire contract. You do need to check whether the tool still fits the original approval conditions.

Your business process changes

Winning a client in a regulated sector, handling new categories of personal data, or making a tool the system of record for a critical process can raise the risk level. The tool has not necessarily changed. Your use of it has.

A twenty-minute revalidation routine

When the date arrives, keep it boring. Open the register entry and check five things.

1. Owner and purpose. Who uses this, for what, and is that still true?
2. Access. Who has admin rights? Is single sign-on enforced? Are leavers removed promptly?
3. Data. What goes in, where is it stored, who else processes it, and how long is it kept?
4. Cost and contract. What is the renewal date, current price, notice period and auto-renewal term?
5. Fit. Is there a credible simpler or cheaper alternative, or a reason to consolidate?

Record the outcome in one line: reapproved, approved with conditions, replace, or retire. Set the next review date. If conditions are attached, write them down and give them their own deadline.

When the date arrives and nobody answers

The review date should not be decorative. If it passes without a decision, do not let the tool drift into another year by default. Freeze new integrations and new seats until the owner responds. Tell finance before the renewal is processed. If the tool is business-critical and the owner is unavailable, arrange a short interim approval with a thirty-day expiry and name the person accountable for the longer review.

That sounds formal, but it is often just a message in the team channel and a note in the register. The point is to stop silence from being mistaken for consent.

The date is a prompt, not paperwork

Approval with an expiry date gives UK teams a simple answer to a question that turns up in client security reviews, insurer questionnaires and internal audits: when was this last looked at, and by whom? It also gives you permission to retire tools that nobody loves but everybody keeps paying for.

You do not need a new procurement programme. You need a date, an owner and a short routine that survives a busy month. A seal is only useful if someone checks it still applies.