Unsupported Software and the Shadow Catalog

Ticket 4418 arrives at 09:12 on a Wednesday. "Hi, our proofing tool says an admin has to approve the renewal by Friday or the account locks. Can IT sort this out? Marketing has used it for a couple of years. Thanks!" You read it twice. You have never heard of the proofing tool. You check the software list, the password vault and the invoice folder, and it is in none of them. Eleven people have logins. The person who set it up left in the spring. The renewal is due Friday, and the ticket is, in every sense that matters, yours now.

Nobody did anything wrong. Marketing had a need, a trial was free, the trial worked, and a credit card did the rest. This is shadow IT: software or services a department adopted without IT. This article is part of our series on defining what IT supports. The sibling articles on the service catalog and scope boundaries cover the list of what IT provides and the lines around it. This one is about the software that was already running before you drew either.

It covers how a shadow catalog forms and why the desk hears about it last, then how to find it without starting a witch hunt. Next comes a three-way list (supported, tolerated, forbidden) with a one-sentence test for each. We cover what "support" means for a tool you merely tolerate, then what has to be true before a tool crosses into supported. Then comes who owns the renewal, with a template for the list near the end.

How the Shadow Catalog Forms

A shadow catalog is the set of tools your organization runs that IT did not choose, does not know about, or both. It forms the way a path forms across a lawn: nobody designed it, and it is the shortest route to somewhere people needed to go. The sequence is nearly always the same. A need: proof approvals were getting lost in e-mail. A search: the first result with a free trial. A trial: fourteen days, and it worked. A card: the department's own, under the amount that needs a signature. Then time. The trial became the way the department works, and the way a department works is production, whatever the invoice calls it.

Every stage of that sequence is invisible from the desk, because none of them produces a ticket. Nothing broke. Nobody needed an account from us. The tool's own support answered the early questions. IT usually learns a tool exists on the first day it fails. That might be a renewal, a departure, a lost admin password, or an auditor asking where a particular spreadsheet lives. Shadow software is extremely reliable right up until the moment it becomes yours.

It is not a conspiracy, and treating it like one is the fastest way to learn nothing. The department met a real need faster than the official route would have. And the honest response is to make the official route faster, not to make the department sorry. Our job is to know what runs and to say what we will and will not do about each thing. Our job is also to keep the organization's data and accounts somewhere we can reach them. "Why did nobody ask us?" has an answer, and the answer is usually that we would have said no, or taken six weeks to say yes.

Why It Matters Before Anything Breaks

Three things are at stake in a tool nobody owns, and none of them is pride. The first is data: what lives in the tool, who can reach it, and whether it can be exported if the tool goes away. The second is access: who still has a login, including the three people who left last year. The third is money: renewals nobody budgets for, and two departments paying separately for the same kind of tool because neither knew about the other.

The fourth thing, which arrives later, is expectation. Once a technician has touched a tool, it is supported in the minds of its users, whatever the catalog says. That expectation is the real cost of shadow IT to a desk, and it is why the three-way list exists. A list lets you say "we know about it, and here is what we do" before the first fix creates a precedent nobody agreed to.

Ignore all four and you get the predictable outcomes. There is the leaver who can still see the customer list, the renewal that lapses on a Friday, and the audit question answered with a shrug. None of these is dramatic. All of them are avoidable with a list and an afternoon.

Discovery Without a Witch Hunt

The goal of discovery is a list, not a confession, and you have to say so before you ask anyone anything. People hide tools from IT for one reason: they expect IT to take them away. If the first message promises that nothing on the list will be switched off because it is on the list, the list will be long and honest. If it does not, the list will be short, and you will find the rest the hard way, one Friday at a time.

Run an amnesty: a message to every department head asking for every tool in use, with the promise above in the first line. Make it a form with four fields: the tool, what it is for, who administers it, and who pays. Give it a week. A free-text e-mail invites essays; a four-field form invites answers.

Then check the amnesty against four sources that do not depend on memory. The ticket history, searched for "login", "renewal", "subscription", "trial" and "invite", finds tools that surfaced once and were forgotten. The finance export, twelve months of card and invoice lines with "software", "subscription" or "license" in the memo, finds everything with a price. The sign-in logs, where you have a central sign-in, list the applications connected to it. Where you do not, the mail server's logs for subject lines such as "welcome to" and "your account has been created" are a usable substitute. And the conversation: fifteen minutes with each department head, after the amnesty, asking "what do you use that we did not give you?" The finance export is the most honest witness, because it never wanted a tool. It only paid for it.

Write everything down in one place as it arrives, with a status of "unsorted" for all of it. Sorting is a separate afternoon. Mixing discovery with judgment slows both, and makes people cautious halfway through the list.

The Three-Way List: Supported, Tolerated, Forbidden

Every tool on the list goes into one of three categories, and each category has a one-sentence test. Supported means IT administers the tool and is accountable for it. We hold the contract or a copy of it, we create and remove accounts, and there is a knowledge base entry. When it breaks we fix it or chase the vendor on your behalf. The test: if it vanished tonight, would we rebuild it tomorrow?

Tolerated means we will not fix it, but we will not block it. We know it exists, a named person in the department owns it, and the vendor's support is the support. The test has two parts. The tool holds no data we would have to answer for (no customer records, no payroll, no passwords for other systems). And there is a way to remove a person's access when they leave. A tool that passes both is tolerated by default. This is the category most of the shadow catalog ends up in, and that is the correct outcome, not a failure of nerve.

Forbidden means the organization must not use it, and the entry says why and what to use instead. The test is any one of three. The tool holds data we are responsible for in a place we cannot audit or export. Or it creates a second copy of a record that a supported system already owns, so that two versions of the truth drift apart. Or it bypasses the security floor, usually by sharing one login among many people with no way to revoke it. A forbidden entry without a sanctioned alternative is not a policy. It is an invitation to find a second shadow tool.

The three-way list is the catalog's shadow side. The service catalog, which is the written list of what IT provides, to whom, and how to ask for it, says what we offer. This list says what we think of everything else. Both belong on the same page, and the scope boundaries article covers where "the department's own software" sits among the other gray areas.

What Support Means for a Tolerated Tool

Support for a tolerated tool is two things and no more: an account is created when someone joins and removed when they leave. Both are done by the department's named owner, not by IT. And the only thing IT does is put the tool's name on the onboarding and offboarding checklists so the step cannot be forgotten. That is the whole service. It fits in one line of the catalog.

Everything else goes to the vendor. "It is slow", "the export is wrong", "can it do this" and "I forgot my password" all get the same polite predefined reply. It names the tool's status, names the department owner, and gives the vendor's support address. Write that reply once and keep it. It will be the most-used reply on the desk within a month, and the users receiving it are not being refused. They are being pointed at the people who can help.

The reason for the hard line is precedent. The first time IT fixes a tolerated tool, it becomes supported in every mind except the one that writes the staffing case. I once spent an afternoon on a tolerated tool's export because the person asking was kind and the problem was interesting. The tool was, from that afternoon on, mine. Nobody decided that. It just became true.

When the line slips, the result is an unfunded service. The desk spends real hours on a tool with no entry, no contract and no vendor relationship. The time comes out of the services that are in the catalog. The user who asked did nothing wrong by asking. The desk did something wrong by not having an answer ready.

Bringing a Tool In: Tolerated to Supported

A tool moves from tolerated to supported when IT decides to be accountable for it. That decision should be made against a short list rather than by whoever answers the ticket. The list is the same every time.

• A named business owner remains in the department. IT administers; the department still owns the reason the tool exists.
• The contract, or a complete copy of it, is in IT's hands, with the renewal date and the notice period.
• A person's access can be removed without the vendor's help, and the admin account belongs to a role rather than to an individual.
• The data can be exported in a format another tool could read.
• More than one department uses it, or one department cannot work without it.
• It has sat in the tolerated column for at least a quarter without causing a ticket IT had to handle anyway.
• The knowledge base entry exists before the status changes, not after.
• The desk has the hours. If the honest answer is no, the tool stays tolerated and the gap goes in the staffing case.

The last item is the one that gets skipped, and it is the reason the list exists. Supported is a promise with a "what to expect" column attached, and those words bind the desk the day they are published. Promising support for a tool you have no hours for is not generosity. It is a future apology with a ticket number.

The Renewal Question

The department that uses a tool owns its renewal, unless the tool is supported. In that case IT owns the contract and the department keeps the budget line. Write which it is in the list, in a column called "renewal", with a date and a name. A renewal with no name attached is renewed by the vendor, automatically, for as long as the card holds out.

IT's role at renewal time is adviser, not approver. Thirty days before the date, the owner gets three questions from the desk. Do you still use it, does anyone else here use something similar, and is there now a supported tool that does the same job? The answers decide whether the renewal goes ahead, shrinks, or stops. The desk does not decide. It asks on time, which turns out to be most of the value.

Back to ticket 4418. At 09:40 Sam replies to Priya in marketing: "We did not know this tool existed, which is not your problem to fix. It is now on our list as tolerated, with you as the owner unless you would rather it was someone else. The renewal is marketing's to approve. Before Friday we need three things. We need a copy of the invoice sent to finance, and the admin account moved from the person who left to you. We need the renewal date in our register so we can ask you three short questions next time, thirty days early." Priya moves the admin account at 11:05, finance confirms the invoice at 14:30, and the renewal is approved on Thursday at 15:20. The eleven logins are checked against the staff list; two belong to people who have left, and Priya removes them. IT's total time on the ticket is fifty minutes, and most of that was writing the list entry.

A War Story: Nineteen Tools at Northgate Retail

Northgate Retail's desk ran an amnesty one spring, after a renewal lapsed and locked the buying team out of their sample-tracking tool for a weekend. Lena sent the message on a Monday with a four-field form attached. By the following Friday nineteen tools had come in from six departments; IT had heard of four of them. The desk sorted the list over two afternoons. Four became supported, including the store scheduling tool every branch manager used. Twelve were tolerated, with a named owner each. Three were forbidden because they held customer contact details behind a shared login with no export. Those three were replaced by a supported alternative within the quarter, on the departments' own budgets. Nobody's name appeared on the published list except in the owner column. The next amnesty, a year later, came back with twenty-six tools and no surprises.

I have run two of these. Both times the list was longer than I guessed. And both times the thing I was most worried about turned out not to be on it.

The Three-Way List Template

The table below is the list's internal version, the one with the criteria and the reasons. Copy it, delete the example rows, and fill it from the amnesty. The published version for users carries the status, where to get help, and the entries themselves, and leaves the reasoning in the agents' copy.

Keep the list in two places. The published version lives on the "what we support" page. That way, anyone can see which column a tool is in before they open a ticket. The internal version, with the criteria column and the finance notes, is for agents only. A knowledge base with visibility states makes that split one setting rather than two documents. QuerySolv's knowledge base has three (published, agents only, draft), which is about the shape this needs. The publishing article covers the page the public version sits on.

Keeping the List Alive

The amnesty is not an event. It is a form that stays open. Put a link to the four-field form on the scope page, and add "which tools will this person need?" to the onboarding form. Tell department heads that a new tool goes into the tolerated column by default on the day they tell you about it. The default matters. If the only way to register a tool is to argue for it, nobody will register one. If registering is free and tolerated is the default, the list stays true on its own.

Review the list once a quarter, in an hour, with three questions per row. Is it still in use, has its data changed category, and has the owner left? Most rows will not move. The ones that do are the ones that would otherwise have become a Friday ticket.

The tool nobody told you about is still out there somewhere, with a trial that became production and an admin who has already left. That is fine. It is on next quarter's list. A desk with a three-way list does not know about every tool. It has a column ready for the next one, and a reply written before the ticket arrives.

Frequently Asked Questions