The Software Your Team Bought Without Telling You

It is rarely dramatic. The design team has a subscription on somebody's personal card, reclaimed on expenses each month. Sales keeps a second list of prospects in a spreadsheet because the real system is slow to load. A project runs in a task board nobody in IT has ever seen. Large drawings go out through a file transfer site because they bounce off email.

Then the ones that grow teeth. A customer service group handled in a messaging app on personal phones, where the history belongs to whoever set it up. A shared cloud folder in a personal account that the whole team now depends on. A scheduling tool that started as one person's experiment and is now how a department plans its week.

None of that was a decision to defy anybody. Each started as one person solving one problem on a Tuesday, and each became load bearing gradually enough that nobody noticed the moment it did.

You will also turn up the ones that were approved once and then forgotten. A tool bought for a project that finished, still billing every month, still holding customer records, with an administrator who left the business last year. Those land in the same pile in practice, because nobody owns them and nobody is watching them. They are usually the easiest to clear up, since nobody will defend them.

Four reasons, and only the last is anything like a rule being broken. They asked and were told no, with a reason that did not address their problem. They asked and it took months, and they had a deadline. They did not know they were supposed to ask, which is far more common than IT departments believe. Or the approved tool genuinely does not do the thing they need, and everybody has been quietly told to make do.

The fourth is worth sitting with. Somebody spent money they had to justify to their own manager, on a tool to do their job better, when a free approved option was already sitting on their desk. That is not laziness. That is a considered judgement that your provision is inadequate, made by the person who does the work.

There is a fifth reason and it would be dishonest to leave it out. Sometimes it is convenience and a rule somebody did not fancy following. That happens. It is a much smaller share than the assumption suggests, and treating every case as if it is the fifth one is what guarantees the next tool never gets mentioned to you at all.

The fastest requirements gathering exercise available to you is a list of what your staff have bought without asking. It costs nothing, it took no meetings, and every entry is backed by somebody spending real money on a real problem.

Survey answers are opinions. A subscription renewing every month is evidence. If three departments have independently bought something to send large files, you do not have a policy problem, you have a file sharing problem, and it has been there long enough for three separate people to solve it privately.

Read the whole list before acting on any single item. The pattern across it is more useful than the individual entries, and it usually points at one or two gaps in what the business provides rather than at a dozen unrelated bits of software.

Then take the list to the department heads rather than to a security meeting. Ask what their tool does that the official one does not, and write the answers down as plainly as they are given. Most of them are small and specific. It opens properly on a phone. It lets a customer reply without creating an account. Attaching a file does not take three clicks. Those sentences are the specification for whatever you buy or build next.

Be accurate about these, because exaggerating them is why nobody listens. Most of the time the tool is fine and the risk is about ownership rather than about the software.

The data leaves when the person does, because the account is theirs. Nothing is backed up, and nobody has ever checked. When the card expires or the person changes role, the service stops without warning and takes the history with it. Customer records exist in a second place, so the two copies disagree and nobody knows which is right. Somebody accepted terms on behalf of your business without the authority to do it. And the renewal charges every year whether or not anybody still uses it.

The real threshold is when it becomes load bearing. A tool one person uses for notes is a preference and not your problem. The same tool once the invoicing runs through it is a system your business now depends on, chosen by nobody, backed up by nobody, and understood by one person who may be on holiday.

Start with finance, because it is cheap, accurate and almost never used for this. Ask for a year of card statements and expense claims and read the small recurring lines. Software subscriptions are unmistakable once you look, and the recurring ones tell you what is actually in use rather than what somebody tried once.

Next, your sign in system. Most business tools let people sign in with their work account, and the identity platform keeps a list of every application that has been connected that way. It is often a long list and it is usually the first time anyone has looked at it.

Then network or web filtering logs, if you have them, which tell you what is being reached. And then simply asking, with an amnesty attached and meant. Say plainly that nothing bad happens to anyone who puts their hand up, and then make sure nothing does, because you get exactly one attempt at that.

Do it in that order. Finance and identity give you most of the answer without a single conversation, so the conversation you do have can be about the gaps rather than the accusation.

Three piles. Most things belong in the first one and it is the pile people forget exists.

Adopt means bringing it in properly. Billing moves to a company account. A second administrator is added so one person leaving cannot lock everyone out. It goes on the inventory with a renewal date. A named owner takes it. Somebody checks what data is in it and whether that is acceptable. Nothing about the tool itself changes, and that is deliberate, because the people using it keep the thing that works.

Replace means moving the need to something you already run, and it only works if the replacement genuinely does the job. Be honest with yourself here. If you are asking people to accept something worse to make your life simpler, say so out loud rather than pretending it is equivalent, or they will use both and you will have made things worse.

Stop is for genuine problems, and it comes with an alternative offered the same day. Taking away the only tool somebody has for a task, with nothing in its place, teaches the whole department never to tell you about the next one.

A business where a new tool request takes a quarter to answer has decided, without meaning to, that its staff will buy software on cards. The rules do not change that. They only change whether anybody tells you.

So build a fast lane. A short request form, a named person who reads it, and a small answer within days rather than a committee within months. Publish what can be approved quickly and what genuinely needs a longer look, so people can see which one they are asking for.

Then say yes to most of it. The vast majority of these requests are a modest subscription for a real task, and the cost of approving something imperfect is much lower than the cost of losing sight of what your business runs on. Spend the caution where it counts.

The short list of things that are genuinely not negotiable is shorter than most policies suggest, and it is much easier to defend for being short.

Personal data about customers or staff going into a service your business has no contract with. Anything that becomes a record you are legally required to keep or produce, because you cannot hand a regulator a personal account. Anything touching payments. And anything where losing access overnight would stop the business, which is why a single personal login on a critical tool matters even when the tool itself is fine.

Explain those four in terms of what happens rather than by citing a policy number. People follow rules they understand and route around rules they do not, and you will get far more voluntary disclosure from a team that knows why the line is where it is.