The Application Lifecycle

Applications have a lifecycle whether or not anyone manages it. Naming the stages shows where the process is missing.

The stages

Request. Someone needs something. Where there is no route, this stage happens on a corporate card and the rest of the lifecycle never starts.

Assess. Security, data, contract, and whether the organisation already has something that does it. This is where duplicates get caught, and it is the stage most often skipped for low-value purchases.

Acquire. Contract, terms, payment method, term length, notice period. Recorded somewhere findable.

Deploy. Accounts created, SSO configured, users provisioned, owner assigned, data classification recorded.

Operate. Access reviews, seat management, support, integration changes.

Review. Periodically: still needed, right number of seats, right tier, still the best option.

Retire. Export the data, notify users, cancel with notice, close accounts, confirm deletion by the vendor.

Most organisations do acquire and operate. The other five are where the problems live.

What each missing stage costs

No request path produces shadow IT, which is a symptom rather than a fault.

No assessment produces duplicate tools and unreviewed data exposure.

No recorded acquisition produces renewals nobody sees coming and terms nobody can find.

No deployment discipline produces applications outside SSO, with no owner and no classification.

No review produces the twenty to thirty percent of unused seats that most first measurements find.

No retirement process produces cancelled subscriptions whose data still sits with a vendor, and accounts that remain open.

The stage nobody designs

Retirement is the least defined and the one with the sharpest consequences.

Cancelling a subscription is not retirement. The account may persist on a free tier. The data remains with the vendor. Integrations keep running until they fail.

A retirement checklist:

Export the data, in a usable format, and verify it opens.

Notify users with a date and an alternative.

Reassign or archive anything that other systems depend on.

Disconnect integrations and revoke OAuth grants, in both directions.

Cancel formally, in writing, respecting the notice period.

Request deletion of your data and record the response.

Remove the payment method.

Close or downgrade remaining accounts.

Mark the register entry retired with the date.

Nine steps. Skipping the deletion request is the most common omission and the one that matters for a data protection enquiry.

Where the lifecycle should be enforced

At acquisition, by making a payment method conditional on registration. This is the strongest available control and it belongs to finance rather than IT.

At deployment, by making SSO the default and local accounts an exception requiring a reason.

At offboarding, which is covered separately and is where most access failures occur.

At renewal, which is a natural review point that arrives on its own.

Making the request path fast enough to use

The whole lifecycle depends on the first stage being used, and it is used only if it is faster than a card.

A form with five fields, not a procurement process.

A tiered response: low risk and low cost answered in days; anything touching sensitive data or exceeding a threshold gets a fuller review.

A published catalogue of what is already licensed, so the first answer is frequently "we already have that".

A named person who responds, rather than a queue.

If the sanctioned path takes three weeks, the lifecycle will keep starting at stage three, and no amount of policy changes that.

The retirement that nobody finishes

Applications are cancelled far more often than they are retired, and the difference shows up months later.

The integration still running. A scheduled job pushing data to a service you stopped paying for, failing silently or, worse, succeeding.

The free tier. Cancelling a paid plan frequently downgrades rather than closes, leaving the data in place and the accounts active.

The OAuth grants, which survive the subscription entirely.

The payment method, still attached, ready to be charged when someone reactivates.

The data, held by the vendor under whatever their retention policy says, which you have not read.

Check each of these thirty days after a cancellation. It takes ten minutes per application and it is the difference between a subscription ending and an application being retired.

The stage boundaries worth enforcing

Not every transition needs a gate. Three of them do, and enforcing those three carries most of the value.

Acquire. A payment method conditional on registration. Held by finance, and the strongest control available.

Deploy. SSO by default, with local authentication requiring a recorded exception and a reason.

Retire. The nine-step checklist completed and signed off, rather than a cancellation.

The other four transitions can be light, and making them heavy is what causes people to bypass the whole path.

Enforcement belongs where the leverage is: the payment control with finance, the authentication default with IT, the retirement sign-off with the register owner.