Ownership: The Field That Makes It Work

Every field in an application register matters less than one: who is accountable for this application still being needed.

Why it matters more than the rest

Renewals get questioned. An owner asked annually whether it is still needed sometimes says no. Nobody says no on behalf of an unowned application, so it renews forever.

Someone answers questions. Security wants to know what data is in it. Finance wants to know why the bill rose. Without an owner, those questions land on IT, who do not know.

Seats get reviewed. An owner shown a list of users who have not logged in for six months will act on it.

Retirement happens. Applications are retired by someone who decides to, and unowned applications are never retired.

Who the owner is

A business person, not IT. IT owns the platform, the integration and the security posture. The business owner owns whether the thing is worth paying for.

A named individual, not a department. Departments do not answer email.

Someone senior enough to cancel it, or the role is decorative.

Ideally the person who requested it, or their successor.

Where it breaks

The owner leaves. The most common failure. Ownership has to be reassigned as part of offboarding, and almost no offboarding process includes it.

Reorganisations, which orphan applications wholesale.

The owner does not know they are the owner. Assigning ownership in a spreadsheet without telling anyone produces a field, not accountability.

The owner has no authority over the budget line.

Nobody asks them anything, so ownership means nothing in practice.

Making it real

Tell them, in writing, what it means. Annual review of need and seats, first contact for questions, decision on renewal.

Ask them something, on a schedule. Ownership that is never exercised is a label.

Include it in offboarding. A leaver's owned applications appear on the checklist and must be reassigned before their access is closed.

Review after reorganisations.

Report unowned applications as a metric. A rising count means the process has stopped working.

Put the owner's name in the renewal alert, which is the moment ownership actually pays.

The quarterly question

One email per owner per quarter, three questions:

Is this still needed?

Are these the right people with access? With the list attached, and the last login date beside each name.

Has what it holds changed? New data types, new integrations, new regions.

Most replies are yes, yes, no, and take a minute. The value is entirely in the minority that are not, and in the fact that the question is asked at all.

What it produces

Organisations that assign and exercise ownership typically find, in the first year:

Applications cancelled because the owner confirmed nobody needed them.

Seats reduced, because the owner recognised names of people who left.

Duplicates identified, because two owners realised they were buying the same thing.

Data classification corrected, because the owner knew what was in it and the register did not.

None of that requires a platform. It requires a name in a field and one email a quarter.

Reassigning ownership when someone leaves

The most common way ownership decays, and the fix is a query rather than a policy.

Generate the leaver's owned applications from the register as part of offboarding.

Send the list to their manager with a request to name a successor per application, not per department.

Set a deadline before the access removal date, so the handover happens while the departing person can still explain things.

Where no successor is named, ownership defaults to the manager rather than to nobody. A default owner who is annoyed about it is more useful than an empty field.

Flag applications that have changed owner twice in a year — usually a sign that nobody genuinely wants it, which is itself an answer about whether it is needed.

Report unowned applications monthly. A count that only rises means this step is not running.

When the owner says it is not needed

The whole point of ownership is producing this answer occasionally, and the process has to handle it.

Confirm the scope: the whole application, or a subset of seats.

Check who else uses it, since an owner may not know about another team.

Check dependencies: integrations, automations, reports pointing at it.

Check the contract: can it be cancelled now, or only at renewal with notice.

Plan the retirement properly, using the nine-step checklist, rather than simply cancelling the subscription.

Record the saving and attribute it to the owner, which is what makes the next owner answer honestly rather than defensively.