Software spend · August 9, 2026

Shadow IT: what shadow IT means, the real risks, and how to find the apps nobody told you about

Shadow IT is any software, service, device or cloud account used for work without the IT department's knowledge or approval. Most of it is not malicious. It is a normal business tool, bought on a company card, by someone doing their job faster than the approval process would have allowed. The defining feature is not the tool, it is that nobody responsible for security, data or renewals knows it exists.

Almost every article on this subject opens with a frightening percentage of IT budget. For SaaS specifically, the real numbers point somewhere more interesting. Zylo's 2026 SaaS Management Index found that shadow IT accounts for just 4 percent of an organization's SaaS spend, but 34 percent of the SaaS portfolio. Roughly one in three applications your company uses arrived without IT, and together they cost almost nothing.

Shadow IT is a count problem, not a cost problem

That inversion is worth sitting with, because it changes what you should do about it. If a third of your applications represent a twenty-fifth of your spend, then shadow IT is made of cheap tools: a seat here, a small monthly plan there, plenty of them under a hundred dollars a month. Chasing it as a cost-cutting exercise produces a disappointing savings number and a program that quietly loses its funding after one quarter.

But every one of those cheap tools is a place company data can live and an account that can still be logged into. Risk does not scale with price. A twelve dollar a month file converter that processed a folder of customer contracts is a bigger exposure than a two hundred thousand dollar ERP that your security team assessed, penetration tested and wired into single sign-on. The correct framing for an executive conversation is not "we are wasting money on unapproved software". It is "a third of the applications touching our data have never been reviewed, and we cannot list them".

What does shadow IT mean?

The term means technology operating in the shadow of official IT: outside the approval process, outside the asset inventory, and outside the security controls applied to sanctioned systems. It is broader than unapproved SaaS. It covers personal cloud storage used for work files, unmanaged laptops and phones, cloud infrastructure accounts opened on a personal card, browser extensions with access to internal systems, and automations wired between tools by someone in operations who is very good at their job.

What are examples of shadow IT?

A designer expensing a Figma seat because procurement takes three weeks. A sales team buying its own scheduling tool. An engineer opening a cloud account on a personal card for a prototype that then runs in production for two years. Files shared through a personal Dropbox because the sanctioned system would not accept a four gigabyte video. A department paying for a project management tool the company already licenses company-wide. Zylo's data points at the same three categories repeatedly: online training, collaboration, and project management are where the redundant, self-bought applications cluster.

Notice what those examples have in common. Every one of them is a person solving a real problem. None of them look like a policy violation from the inside, which is exactly why telling people to stop does not work.

Why is shadow IT a risk?

Because company data ends up in systems nobody has assessed. Unknown apps sit outside single sign-on and multi-factor authentication, they are not covered by your data processing agreements, they keep working after an employee leaves because offboarding never touched them, and they cannot appear in a breach or compliance report when nobody knows the account exists.

Break that into the four exposures that actually bite:

The last row is the smallest number and the easiest one to act on, which is why it is often where a program starts. It is also the row that produces a list you can hand to security, and that hand-off is the whole point.

What is shadow AI?

Shadow AI is the AI-specific case of the same problem, and it is the fastest-growing part of it. The entry price of a capable AI tool is low enough to disappear into an expense report, so adoption runs far ahead of review. The risk profile is also sharper than ordinary shadow SaaS, because with most tools the sensitive data is what you store in them, while with an AI assistant the sensitive data is frequently the input itself: the contract being summarized, the customer list being cleaned, the codebase being explained.

The newer version is harder still. Employees are no longer only pasting text into a chat window, they are connecting agents to real systems with real credentials, which turns a question about data handling into a question about what those agents are allowed to reach and what they can do once they get there. Treat that as its own discipline rather than a footnote to your SaaS policy, because the blast radius is different.

How do you detect shadow IT?

Four methods, and each is blind to a different slice. Identity provider logs show apps reached through single sign-on. Browser extensions or endpoint agents show apps opened on managed devices. Network and secure web gateway logs show outbound traffic to cloud services. Card, expense and accounts payable feeds show anything that generates a charge, which is the only method that sees an app IT has never heard of.

Run through those in order and the structural gap becomes obvious. Single sign-on cannot show you an app that was never connected to it, and no shadow purchase ever is, because the buyer had no reason to ask. Browser telemetry needs the extension deployed and misses phones and contractors. Network logs see traffic but not what was bought or what it costs. Only the financial trail is generated by the act of buying, which means it is the one signal that exists from day one of an unsanctioned tool's life.

That is why the practical starting move is cheaper than most teams expect. Pull twelve months of card and accounts payable transactions, group them by merchant, and mark every merchant that charged you more than twice at a regular interval. Compare that list against the applications you can name. The gap is your shadow IT inventory, it took an afternoon, and it cost nothing. The step-by-step version of this exercise is in how to run a SaaS subscription audit, and the benchmark for what the total should look like is in average SaaS spend per employee.

Once the manual pass has proved the problem is real, the tooling question is which of the four signals you want combined and automated. That is the job of a SaaS management platform, and the comparison there covers which vendors publish a price and which discovery methods each one leads with.

How do you prevent shadow IT?

You mostly cannot prevent it, and programs built on prohibition fail. What works is reducing the reason for it: a fast, published route to request a tool, a short approved catalogue that covers the common needs, and detection that catches new purchases in days rather than quarters so the conversation happens while the tool is still easy to move.

Four things that measurably help, in rough order of effort:

• Publish the request path and put a clock on it. Most shadow purchases happen because nobody knew how to ask, or asked once and heard nothing. A named owner and a stated turnaround removes most of the incentive.
• Make the approved catalogue short and real. A list of forty sanctioned tools that nobody reads is the same as no list. Cover the five categories people actually buy in and say plainly what to use.
• Set a card rule that routes rather than blocks. Any recurring software charge above a threshold gets flagged for review. Not declined, reviewed. The goal is a conversation within the week, not a locked card and a resentful department.
• Amnesty first, enforcement second. Open with a window where anyone can declare a tool with no consequence. You will learn more in two weeks than detection gives you in a quarter, and you will not spend the rest of the program being lied to.

Is shadow IT always bad?

No. Shadow IT is a signal as much as a problem. A department that bought its own tool usually had a real need and no fast way to meet it, and the tools employees pick themselves are often the ones they will actually use. Plenty of software that is now standard in large companies entered through a single team's credit card. The goal is to bring these tools under governance quickly, not to punish the purchase or rip out something that works.

The failure mode to avoid is the audit that arrives eighteen months late, cancels forty subscriptions, and teaches everyone that the correct response to a software need is to hide it better. Speed of discovery is what separates a governance program from a purge. Catch a new tool in the week it is bought and you get a five minute conversation about data handling. Catch it in year two and you are unpicking a workflow the team now depends on.

The shortest useful version

Shadow IT is about a third of your application portfolio and almost none of your software bill. Treat it as a data and access problem, not a savings project, or you will win the argument and lose the budget. Start with the payment trail because it is the only signal that exists from the moment a tool is bought, run an amnesty before you run detection, and measure the program on how quickly a new application becomes known rather than on how many you cancelled.

Spendnotify watches the transaction stream on the cards and accounts you already have and alerts you when a new recurring merchant appears, when a subscription renews at a higher amount, or when a software budget is breached. It is read-only and it will never decline a charge, so it does not stop a purchase. It changes how long that purchase stays invisible. See subscription monitoring for how the recurring-charge view is built.