Unapproved Software Asks and the Shadow IT Conversation

Thursday, 09:50, at Bluewater Bank. Yusuf has four tickets from the morning's triage open side by side, and none of them is on the catalogue. Ticket 5102: "Can you install the free PDF merger? Link attached." Ticket 5104: "I need the browser extension that clips pages into my notes; everyone in marketing has it." Ticket 5107: "I bought the diagramming program on my own card, can you put it on my work laptop?" Ticket 5109, from a team lead in trading support: "Our whole team already uses the group-chat app on our phones for shift handovers. Can IT make it work on the desktops?" Four requests, four shapes, and under each one the same question: is the bank willing to run this? None of the requesters has asked it because none of them thinks of it as a question.

Unapproved software is any program, extension, add-on or online service that is not on the catalogue and has not had the security look described in Approvals Without a Committee. Shadow IT is unapproved software that a person or a team has already adopted, usually for a good reason, without the desk knowing. Neither is a crime. Both are a request the desk has to answer, and the answer has to be about risk. It is not about whether the thing is free, whether the requester paid for it themselves, or how many of their colleagues already have it. This article is part of our Software Installs & Licence Requests series. It is about the four shapes the request takes and the risk-based yes or no. It covers the alternative that goes with every answer and the no that comes with a reason.

It starts with the four shapes of the same request and why "it's free" is not an answer. Next come the browser extension problem and the personal licence. Then it covers the thing the team already uses, which is the shadow IT conversation. It moves on to the risk-based yes or no, the alternative offer and saying no with a reason. A short war story and the unapproved-software reply to copy finish the article.

Four Shapes of the Same Request

The four tickets on Yusuf's screen look different to the requesters and identical to the desk. Each is a request to run something the bank has not looked at, and the differences are in what the requester believes the request is. The free tool's requester thinks it is a request with no cost. The extension's requester thinks it is too small to be a request at all. The personal licence's requester thinks the purchase decision is already made, by them. The team lead thinks the adoption decision is already made, by the team. None of them is being difficult. Each has looked at the request from where they sit. From where they sit the question of risk is invisible, because risk is the organisation's problem and the request is theirs.

The table below shows the four shapes, what the requester thinks each is, what it actually asks of the organisation, and the usual answer. The desk can recognise the shape in the first line of the ticket and reply to the real question rather than the stated one.

Reply to the shape, and reply fast, because every one of these requests has a workaround sitting one click away from the requester. The free tool can be installed by anyone with admin rights and downloaded by anyone without. The extension installs in two clicks. The personal licence is already on the requester's home machine. The team's chat app is already on their phones. A desk that takes a week to answer an unapproved software request has answered it, in the sense that the requester has stopped waiting. The security look takes an hour; the reply should go the same day.

Why "It's Free" Is Not an Answer

"It's free" answers the money question and leaves the other two untouched, and the other two are the ones that matter. A free program still has terms, and the terms of free software are more often the surprising ones. It may be free for personal use and not for business, or free until the supplier decides otherwise. It may be free in exchange for what the program learns from the machine it runs on. The supplier of a free program is paid somehow, and the desk's job in the security look is to find out how. The answer is usually either the data or the upsell. The organisation should know which before it installs the thing on forty machines.

The cost of a free program is desk time and risk, and both are real. For as long as anyone uses it, the desk will install, support and update the PDF merger in ticket 5102. The desk will uninstall it when it breaks something. Each of those is twenty minutes the organisation pays for whether or not the supplier was. The risk is what the program does with the files it merges, which for a bank's documents is not an idle question. A free tool that sends each file to a server somewhere to do the merging has moved the bank's documents off the bank's network. The requester did not know, because the download page did not say, because it never does.

None of this makes free software bad; most of the catalogue at most desks is free, and the security look says yes to the ordinary ones in twenty minutes. It makes "free" irrelevant to the decision. The decision is what the program touches, and what it touches is the same question whether the supplier charged for it or not. (A program that costs money has at least told you how it is paid for. The free one is making you guess.)

The Browser Extension Problem

A browser extension is a program that runs inside the browser. Depending on what it asks for when installed, it can read and change every page the browser shows. At most organisations that includes the mail, the finance system, the records system and anything else that has moved to the web. The requester sees a small icon that clips pages into their notes. The desk sees a program with a view of everything the user does online. It was written by a supplier the organisation has not heard of. That supplier updates it silently whenever they like. The gap between those two views is the whole of the extension problem, and it is not the requester's fault that they cannot see it.

The security look for an extension asks what it wants permission to do, which the browser shows at install time and which is the one piece of evidence the desk has. An extension that asks to read and change data on all sites is asking for everything. The answer for an organisation whose web applications hold anything sensitive is nearly always no, however useful the clipping is. An extension that asks only for the current page when clicked, from a supplier the desk can name, is ordinary, and goes on the catalogue's extension list. Where the organisation's management tools allow the browser to be told which extensions are permitted, the list becomes a setting. In that case, the question stops arriving at the desk at all. Where they do not, the list is a knowledge base article and the desk removes what is not on it when it is found.

Say the reason in one line that the requester would agree with, because the requester's picture of an extension is a small icon and the desk has to replace it with a true one. "An extension can read every page the browser shows, including the ones with customer records, and this one asks to; we can't allow that on a machine that opens the records system" is a sentence a marketing manager understands and, in my experience, agrees with, slightly alarmed. The alternative, which is usually a built-in feature of the browser or the notes program that does most of the clipping, goes in the same reply.

The Personal Licence

The personal licence is software the requester bought themselves and wants on the work machine. The honest answer is that the organisation does not run software it does not hold the licence for. So if the need is real the organisation buys its own seat and the requester keeps theirs for home. The reason is in the terms: a licence bought by a person is usually for that person's own use, on their own devices. Installing it on the organisation's machine is often outside what was bought. That makes the organisation the one in breach when the audit letter from Licence Tracking Without a Tool arrives. The register cannot hold a seat the organisation does not own. The offboarding checklist cannot reclaim it. The next person at that desk cannot inherit it.

The need behind the request is usually real, and that is the thing to answer. The requester bought the diagramming program because they needed to draw diagrams and the organisation's answer was slow or absent. The right response is to thank them for the clue, run the security look, and raise the request properly with the one-line case they have already written. The organisation's seat arrives within the standard turnaround. The personal copy goes nowhere near the work machine. The requester is out of pocket for a thing they bought for their own use, which is what they bought it for. Whether the organisation reimburses them is a finance question, and the desk says so and stays out of it.

Decline the install without declining the person. "I can't put your own licence on the bank's laptop, because the terms tie it to you rather than to us and we'd be the ones in breach. I've raised the request for a bank seat with your note as the business case, and that should be installed within the usual two days" is the whole reply, and the requester who hears it has been told no about one thing and yes about the thing they wanted. The few who argue are arguing with the supplier's terms, and the desk can say so.

The Thing the Team Already Uses

The shadow IT request is different from the other three because the software is already in use and already holds the organisation's data. The desk's first move is a conversation, not a decision. The team lead in ticket 5109 is not asking for permission to start. The team started a year ago, the shift handovers are in the chat app, and so are the customer names in them. The desk cannot say no to something that has already happened. It can only decide what happens next. It cannot decide that until it knows what the team uses the thing for, what is in it, and who else has it. Three questions, asked without a tone, in a conversation that the team lead should leave feeling helped rather than caught.

The three outcomes are adopt, replace, or stop, and each comes with a date. Adopt means the organisation takes the service on properly: the security look, a licence it holds, the data under its control, the service on the catalogue, and the team's year of use retroactively blessed. Replace means the catalogue already has something that does the job. The team moves to it with the desk's help, and the data moves with them. Moving the data is the part that takes the time and the part that gets skipped when the desk only says "use the approved one". Stop means the risk is too high to adopt and there is no equivalent to move to. The team is told why, and the data is got out and the accounts closed by a date. The policy that decides which, and the organisation's stated position on software the desk does not support, lives in Unsupported Software and Shadow IT. This article is the conversation that applies it to one team.

The data is the issue, every time, and the tool is nearly beside the point. A year of shift handovers with customer names in a chat service the bank has no agreement with is the problem. The app itself is one of a dozen that do the same thing, and the bank could run any of them under terms it had read. The desk that leads with "you shouldn't have used that" has started an argument about the tool. The desk that leads with "what's in it, and how do we get it somewhere the bank controls" has started the only conversation that matters. The team lead, who did not know the data was anywhere in particular, is usually the first to agree.

Never punish the discovery, because the desk only finds shadow IT when someone tells it. A team that was lectured the last time does not tell it the next. The team lead who raised ticket 5109 did the organisation a favour. The three other teams using the same app on their phones did not raise a ticket and are still invisible. The desk's reply sets the price of honesty for everyone watching. (They are watching. Shadow IT has excellent word of mouth.)

A Risk-Based Yes or No

A risk-based answer is one that depends on what the program touches and where it runs. It does not depend on who asked, whether it was free, or how many people already have it. The security look from the approvals article supplies the facts: who makes it, what it does with data, what access it wants, what it touches. The decision then falls out of two questions. What does it reach: files on one machine, the organisation's network, the organisation's web applications, or data that leaves the organisation? And what is that data: nothing much, internal documents, or the things the organisation is trusted with, customer records, patient notes, client drawings, the ledger? Low on both is a yes and an entry on the catalogue. High on either is a no, or a yes with conditions that bring it down. The same free tool is a yes for the facilities team's floor plans and a no for the claims team's files. That is not inconsistency; it is the question being asked properly.

Write the risk answer in the ticket in those terms, so that the next request for the same program gets the same answer and the requester can see it was not personal. "Reaches: files on the machine only, nothing sent out. Data: whatever the user opens with it. Supplier: named, terms read, free for business use. Answer: yes, on the catalogue for everyone" takes a minute to write and settles the next twenty requests. "Reaches: every page the browser shows. Data: includes the records system. Answer: no on any machine that opens records; alternative offered" settles the extension question for the whole organisation. The knowledge base entry that says so is where the next requester reads it before asking.

Conditions are the answer for most of the middle, and they are the thing a risk-based decision can give that a blanket rule cannot. Yes, on machines that do not open the records system. Yes, with the setting that sends usage data turned off, and the desk installs it rather than the user. Yes, for this team's floor plans, and the file-sharing feature disabled. A desk that can say "yes, like this" gets the requester their tool and keeps the organisation's data where it belongs. The conditions go into the install record and the catalogue entry so that they survive the technician who set them.

The Alternative Offer

Every answer to an unapproved software request carries an alternative, including the yes, because the alternative is often already installed and the requester did not know. The question that finds it is "what were you trying to do", asked before the answer is written. The answer to that question is usually a task the catalogue already covers. The task might be to merge two documents, which the document reader on the image does. Or to clip a page, which the browser's own reading list does. Or to draw a diagram, which the office suite does badly and the catalogue's diagram tool does well. Or to hand over a shift, which the ticketing system does with a linked ticket and a note. The ticketing system has the advantage of being where the bank keeps its records already. The requester asked for a program. They wanted a task done. The alternative is the task done with something the organisation already trusts, and it is an answer, not a consolation.

The craft of the alternative, and why a no without one is a wall the requester climbs over, is the subject of Offering an Alternative Instead of a Wall. The software desk is where the craft earns the most, because the wall is so easy to climb: the download page is right there. An alternative that does most of the job, available today, beats a perfect tool declined, and the reply says so plainly: "This does what you described except the automatic numbering; if the numbering turns out to matter, say so on the ticket and we'll look at the paid one properly." The door stays open and the requester knows where it is.

Where there is no alternative, say so, and say what the desk will do instead: "Nothing we have does this; I've put it through the security look and will tell you by Friday either way." The thing not to do is to decline the program and offer nothing. The requester will solve their problem some other way by Friday. The desk will hear about the other way from the audit letter or the breach report.

Saying No With a Reason

The no, when it is the answer, has one reason, stated in a sentence the requester would agree with, and nothing else: no lecture, no policy quoted at length, no "unfortunately". "This extension can read every page in the browser including the records system, and that's a risk the bank can't take on a machine that opens records" is a reason. "This is not permitted under the acceptable use policy" is a reference. The requester can argue with a reference, because a reference is a rule somebody wrote; they rarely argue with a reason, because a reason is a fact about their own situation. The shape of a no that holds, and the three parts it has, are in The Anatomy of a Good No. The software no follows it exactly, with the risk answer as the reason and the alternative as the third part.

Record the no with its reason on the ticket and in the knowledge base. That way, the same program gets the same no from a different technician next month. The requester who asks twice can be shown the first answer rather than given a second one. If you run QuerySolv, first link the knowledge base article visible to everyone that lists what the catalogue offers. That way, the requester sees the yes list beside the no. In any tool, the reply should link the list of what they can have. A no that arrives with a catalogue reads as help and a no that arrives alone reads as a wall. The requester who replies to argue reopens the ticket, and the argument goes where it belongs. It goes to the person who owns the risk decision, in writing, not to the technician who delivered it.

Count the nos by program once a quarter. Three teams asking for the same unapproved tool is not three people who skipped the policy. It is a need the catalogue does not meet, and the desk is the only place that can see it. The right response is a proper look at the tool or a licensed equivalent, raised by the desk on the teams' behalf, which is the subject of Reducing Software Request Friction. The nos are data.

A Short War Story: The Free Transfer Service at Pinewood Architects

Pinewood Architects' studio of thirty had been sending drawings to clients through a free file-transfer service for two years. The files were too big for mail. The desk was a single technician called Priya who had inherited the practice. She had said no to the paid version of the same service on cost grounds and offered nothing in its place. The service changed its terms in the spring so that links were listed publicly unless the sender paid. Nobody at Pinewood read the change. A developer client found the unreleased design for its own flagship building through a search, with the Pinewood name on it. This was a month before the public announcement it had been planning. The practice lost the client and spent about thirty hours with its insurer and its solicitor. It spent a further twenty moving two years of transfers into a service it now holds under terms it has read. That service has the desk's conditions on who can share what. Priya's no had been right about the risk and wrong about everything else. It came with no reason the architects could use, no alternative, and no conversation about where the drawings were going in the meantime. The lesson the practice wrote into its new catalogue page was the one the no had missed. A no without an alternative is not a decision, it is a delay, and the work finds its own way while you wait.

The Unapproved-Software Reply

The reply below is the one Yusuf used for all four tickets that Thursday, with a different block chosen for each. It is written to be sent the same day as the request. The opening is the same in every case: the task the requester described, in their words, so they know they were read. The middle is one of three blocks, chosen by the risk answer: yes and on the catalogue; yes with conditions, or an alternative that does the task; or no with the reason and the alternative. The closing is the same again: the link to what they can have, and the door left open. The lines in brackets are choices, not jokes; take the one that applies and delete the rest.

UNAPPROVED-SOFTWARE REPLY — SAME DAY, ONE REASON, ALWAYS AN ALTERNATIVE
Ticket: ________   Program asked for: ______________________   Shape: free / extension / personal / already in use

Thanks for the request. As I read it, you need to ______________________ (the task, in your words).
I've had a look at ______________ (the program), and here is where we are.

[A] YES, AND IT IS NOW ON THE LIST
  It only reaches ______________ and sends nothing out, so it's fine for everyone to have.
  I've added it to the catalogue; it will be installed on your machine by ________.

[B] YES, LIKE THIS   /   OR THE THING WE ALREADY HAVE
  It's fine with one condition: ______________________________ (for example: installed by the desk
  with the data-sharing setting off / on machines that do not open ______ / for this team only).
  — or —
  ______________ (the catalogue program) already does what you described, except ______________.
  It is on your machine now / I can install it by ________. If the missing part turns out to
  matter, reply here and we'll look at the paid one properly.

[C] NO, FOR ONE REASON, AND HERE IS WHAT WE CAN DO
  I can't approve this one because it ______________________________________ (the reason, in
  plain words: reads every page in the browser including ______ / sends files to the supplier's
  servers / is licensed to a person rather than to the organisation / forbids business use).
  What I can do: ______________________________________ (the alternative, with a date).
  If you think I've misread the need, reply here and I'll take it to ______________, who owns the decision.

[D] IF YOUR TEAM IS ALREADY USING IT
  Thanks for telling us; that helps. Could we talk for ten minutes about what the team keeps in it
  and who else uses it? Nothing is being switched off. We'll agree together whether we take it on
  properly, move to ______________ with your data moved for you, or wind it down by a date you can work with.

Everything you can have without asking is listed at ______________ (the catalogue page).

Ticket 5102 got block A: the PDF merger kept files on the machine and sent nothing out, and it was on the catalogue by lunch. Ticket 5104 got block C, with the reason about the records system and the browser's own reading list as the alternative. The marketing manager replied "hadn't thought of that" and nothing else. Ticket 5107 got block C and a bank seat of the diagramming program two days later. Ticket 5109 got block D and a ten-minute conversation. Then came six weeks of moving a year of shift handovers out of the chat app and into linked tickets. Afterwards, the team lead said the handovers were easier to find and the desk said nothing, which was the correct amount.

Frequently Asked Questions