TL;DR. Shadow SaaS is the SaaS your organisation is using that IT does not formally track. The typical European mid-market firm has materially more tools in active use than its central record shows, and the spend gap can be three times what the IT inventory implies. The cost recovery is real and immediate. The security and compliance exposure is what most teams underestimate, and neither can be addressed without a complete SaaS inventory as the foundation.
Shadow SaaS is the SaaS your organisation is using that IT does not formally track. Your IT team tracks 60 SaaS tools. The real number is meaningfully higher. The missing tools are paying subscriptions to vendors you may not have heard of, holding personal data you didn't realise had been shared, and renewing automatically next month.
That gap has a name. Shadow SaaS is the operational tax of distributed software adoption, the SaaS in active use that is not on the IT register, is not in the procurement system in any current form, and is not being assessed against the security and compliance obligations the rest of the stack is. It overlaps with the older shadow IT category but has different mechanics, and matters for different reasons in 2026 than shadow IT did in 2018.
This piece is for the IT director who has just spent two days reconciling renewals, suspects there is more sprawl beneath the surface than the data suggests, and wants the operational framing without the marketing wrapper.
Definition and Scope
Shadow SaaS is any cloud-delivered application in active use within your organisation that is not on the central IT inventory.
The "active use" part is doing real work in the definition. A SaaS contract that lapsed last year is not shadow SaaS, it is a stale record. A SaaS that someone in marketing tried for a week six months ago is not shadow SaaS, it is evaluation noise. A SaaS that a team is using daily, paying for monthly, and storing customer data in, that the IT inventory does not list, that is shadow SaaS.
Three subcategories sit inside the definition:
Unsanctioned. Tools the central function never approved. The marketing team's competitive-intel platform on a personal credit card. The engineering team's monitoring tool on a team budget code. The HR coordinator's scheduling tool subscribed to with a personal Google account.
Partially sanctioned. Tools approved for one team or one use case that have spread well beyond the original scope. The Notion workspace originally licensed for product documentation, now holding finance models, customer contracts, and HR personnel files. The Slack integration approved for the sales team that engineering also adopted three months later without notice.
Formerly sanctioned. Tools approved years ago, where the original sponsor has left, the vendor has been acquired or pivoted, the licence terms have materially changed, and nobody is currently performing the operational role of monitoring whether the tool still belongs in the stack. These are the renewal surprises, auto-renewing subscriptions for tools nobody can name an owner for.
The combined population is measurable. IBM's 2025 Cost of a Data Breach Report found that 63% of breached organisations either have no governance policy for AI-enabled tools or are still developing one, and among those with policies, only 34% perform regular audits to detect unsanctioned tools. Gartner estimates enterprises will spend more than $300 billion on SaaS in 2025, with 25% of every dollar wasted on unused or underused resources. In Discovery Audits we have run at firms in the 200–2,000 employee range, the central-record-versus-actual-use gap is typically two to three times, meaning a firm whose SaaS inventory lists 60 tools is usually running 150 or more, with the bulk of the difference in low-cost, department-budgeted, or personal-credential subscriptions.
Why Shadow SaaS Exists
Shadow SaaS is not a discipline failure. It is a structural consequence of how organisations buy software now.
The pre-2015 model was central. New software was a capital-expense decision, took weeks of evaluation, ran through procurement, and was implemented by IT. The procurement gate caught everything because there was no other way to buy.
The post-2015 model is distributed. SaaS-by-credit-card lowered the procurement floor to zero. A team lead with a corporate card and a need can adopt new software in five minutes, before any procurement gate sees it. The expense system catches the charge eventually; the IT inventory never does, because the inventory is a manually maintained spreadsheet that nobody updates from expense data.
Three forces compounded this. Department-led tooling: marketing went from one or two platforms to thirty or forty point solutions; engineering went from a small handful of devtools to dozens; sales went from CRM and dialer to twenty-tool stacks. Post-pandemic remote-work tool sprawl in 2020 onwards drove rapid adoption of collaboration, asynchronous communication, and virtual whiteboarding tools, many of which were never revisited. And the AI overlay since 2022 has added AI-specific point solutions and AI-enabled versions of existing tools across every department, faster than central IT can review them.
The fix is not more procurement gates. It is a SaaS management and tracking layer that catches up with the buying patterns that already exist.
The Financial Picture
The cost-recovery framing is the most immediate ROI hook for software inventory management work. The numbers, in our audits and in the broader industry data:
Published industry benchmarks are consistent. BetterCloud's recent State of SaaS reports indicate average SaaS spend per employee in the high hundreds of euros annually for mid-market firms. Productiv's app utilisation data has consistently shown that across discovered SaaS portfolios, average actual utilisation of paid licences sits well below the contracted seat count. Gartner research indicates organisations without a centralised SaaS plan typically overspend by at least 25%.
The waste, in our audits at European mid-market firms, concentrates in three patterns:
Duplicate tools. Two or more vendors providing overlapping capabilities, adopted by different teams at different times. Three different observability tools across engineering teams; two project management platforms across product and operations; two competing analytics platforms across marketing and sales. Each was a reasonable decision at the team level; the aggregate is paid duplication.
Departed-employee retention. Licences for people who have left the firm but whose accounts persist because no one has the deprovisioning workflow tied to off-boarding for that specific tool. Even at firms with mature SSO-based deprovisioning, tools outside SSO are routinely retained. In a 1,000-person firm with 8% annual attrition, eighty active accounts churn every year; the corresponding SaaS licences often do not.
“In every conversation I have had with IT directors regarding the shadow SaaS, the former employee problem lands hard. Not the tool, not the spend figure, it is the realisation that there are forty or fifty active accounts that belong to the people who left months ago. Credentials still exist, the tool is still processing data, and the firm cannot revoke the access because they never knew the tool was there.” - Ankur Arora, Co-Founder, Montro |
Underutilised seats. Contracted seat counts that do not match active use. The classic pattern: a 50-seat licence renewed annually for a tool that nine people actually use. The cost optimisation is right-sizing the contract at renewal, but only if the firm can produce defensible utilisation data, which it cannot if the tool is not on the inventory.
The recoverable spend across these three patterns, in audits we have run, typically lands in the 18–28% range as a share of total SaaS spend in the first twelve months of structured discovery work. The exact figure varies by sector and by how much rationalisation has happened previously. Engineering-heavy firms typically recover at the higher end of the range; firms that have done a previous SaaS rationalisation programme recover less because the easier wins are already taken.
The CFO conversation is straightforward. If your firm spends a meaningful sum annually on SaaS, the recoverable share is materially larger than the cost of the discovery work that surfaces it. The investment case is rarely the hard part of these conversations. The hard part is operationalising the rationalisation once the data exists, a different problem from the discovery problem.
The Security Picture
Cost recovery sells the project. Security exposure justifies it.
The IT director's instinct is that shadow SaaS creates a vendor-risk problem. That is correct, and incomplete. Three security dimensions matter:
Vendor risk you cannot assess. Every SaaS in use is a third-party data processor with access to organisational data. Vendors not on the inventory have not been through vendor risk assessment, have not been reviewed for security certifications, have not been examined for breach history, and are not being monitored for security incidents the firm should know about. When a security incident at a small SaaS vendor makes the news, the central security team should know whether their firm uses that vendor. Without an inventory, they cannot.
Identity sprawl. Shadow SaaS adoption typically happens outside the firm's identity provider, through personal credentials, through "sign in with Google" using personal accounts, through magic-link authentication tied to corporate email but not federated through the SSO. The result: tools the firm depends on are accessed through credentials the firm cannot revoke. When an employee leaves, their access to the central stack disappears at off-boarding; their access to shadow SaaS persists.
Data residency surprises. Many SaaS tools, particularly newer AI-adjacent tools, run outside EU data residency by default. The team that adopted the tool did not notice the region setting; the data they uploaded - customer information, internal documents, code - is now sitting in a US-east region or an Asia-Pacific region with no record of how it got there. Discovery does not fix this on its own, but it surfaces the population of tools that need region review.
The pattern across the three: shadow IT is not just a security risk because of the unknown vendors themselves. It is a risk because the firm has lost the ability to make informed security decisions about its own environment. The starting point of any meaningful SaaS governance programme is knowing what is there.
The Compliance Picture
The compliance dimensions of shadow SaaS are less obvious to the IT audience but increasingly matter as European regulation has tightened.
GDPR Article 30 - the stale RoPA problem. Every SaaS that processes personal data is a processor under GDPR Article 28, and each processing activity should be on the controller's record of processing activities under Article 30. The Article 30 RoPA goes stale every time a new tool enters the environment without the DPO knowing - purposes change, data categories may change, recipients change. Shadow SaaS is the largest single source of RoPA decay at most mid-market firms, and the case for continuous SaaS management as a compliance obligation, not just a cost exercise, starts here. The DPO whose register was correct in January is, by July, working from a record that no longer reflects reality.
NIS2 supply chain - Article 21. For firms in scope of NIS2 Article 21 places obligations around supply chain security. The supplier inventory those obligations attach to is the same SaaS inventory the IT team has been keeping. If half the supply chain is not on the inventory, the supply chain assessment is half done.
The AI overlay. Shadow AI - covered fully in our pillar piece on it, is a subset of shadow SaaS with materially higher regulatory stakes. Every shadow AI tool is shadow SaaS plus EU AI Act exposure plus, often, expanded GDPR exposure under DPIA obligations. The shadow SaaS catalogue, classified for AI-feature presence, is the foundation for the AI governance work; finding shadow SaaS is most of the job of finding shadow AI, with an AI-classification pass on top, which is why a complete SaaS inventory is the prerequisite for the AI governance work, not a parallel exercise.
The compliance framing matters because it changes the buyer for the shadow SaaS programme. A pure cost story is owned by the IT director and signed off by the CFO. A cost-plus-compliance story is owned by IT, signed off by the CFO, and supported by the DPO and the CISO, which is the coalition that gets shadow SaaS work funded at the level the problem warrants.
How To Find It - The Four Discovery Layers
No single source of data shows the full shadow SaaS population. Each source shows part of the picture; the four together approach completeness.
Identity. The SSO logs (Okta, Microsoft Entra ID, Google Workspace, OneLogin) capture every sanctioned authenticated SaaS access. This finds the tools that flow through SSO and misses the tools that do not. In most mid-market firms, SSO captures perhaps half of the active tool population.
Email and calendar metadata catches tools the SSO does not. Every SaaS in use sends transactional email; every account creation triggers a confirmation; every shared workspace generates calendar invitations to vendor accounts. Mining this data surfaces personal-account adoption that authentication logs miss entirely.
Browser and endpoint telemetry shows actual usage, including for tools that do not require central authentication - the layer where free-tier and personal-credential adoption surfaces. Configuration and consent matter; in some jurisdictions, browser telemetry needs to be carefully scoped under works council and GDPR rules before it can be used at scale.
Finance and expense data catches paid tools the other layers missed because someone in marketing put the subscription on a personal card and expensed it. The expense management platform, the accounts payable system, the corporate card statements, each one is a partial record of paid SaaS that often does not reach the IT inventory.
The four layers together, run against a current SaaS inventory and against the integrations the firm already operates, surface ninety per cent of the shadow SaaS population within thirty days at most mid-market firms. The remaining ten per cent emerges through interviews with department leads and through analysis of work artefacts that suggest tool use the data layers did not catch.
What To Do Once You Have Found It
Discovery is the start, not the end. A complete inventory creates options that did not exist before; it does not, by itself, fix anything.
The structured pipeline runs in three steps.
Catalogue. Take the discovered population, deduplicate, and resolve to a canonical record. Different teams refer to the same tool by different names; the same vendor sometimes has multiple billing accounts; embedded features inside one tool sometimes show up as separate vendors. The catalogue work converts the raw discovery output into a clean inventory the rest of the work can run on.
Classify. For each tool, capture the dimensions that matter for the firm's downstream use: criticality, data sensitivity, AI feature presence, GDPR processor status, contract terms, owner, region, alternatives. The classification work produces a register that the security, compliance, and finance functions can each operate from.
Govern. Assign each tool an operational owner, usually the originating department lead, sometimes central IT. Establish renewal review processes. Surface duplicates for rationalisation review. Build the security review queue for tools that have not been through one. Build the DPO review queue for tools handling personal data without a DPA in place. Build the AI classification queue for tools with AI features.
The pipeline is straightforward conceptually and operationally heavy in practice. Most of the work is not technical; it is coordination across functions that have not historically worked together. The IT director runs discovery and catalogue. The security team owns vendor risk classification. The DPO owns the GDPR pass. The CFO owns the rationalisation decisions. The work succeeds when the data layer is unified and the people work from the same record, a software inventory management discipline that most mid-market firms are building for the first time rather than inheriting from a prior programme.
Frequently Asked Questions
Is shadow SaaS just shadow IT with a new name?
It overlaps with shadow IT and shares some of the same discovery patterns. It is not the same problem. Shadow IT, in its original framing, was about unsanctioned tools, software employees installed without IT approval. Shadow SaaS is broader: it includes tools that are technically sanctioned but operationally unmanaged, tools that were sanctioned but where the original sponsor has left, and tools where the AI features that turned on last quarter are not what the original sanction covered. The discovery patterns are similar; the mental model has to be wider.
How is shadow SaaS different from shadow AI?
Shadow AI is a subset of shadow SaaS with materially higher regulatory stakes. Most shadow AI tools are SaaS, so finding shadow SaaS finds most shadow AI. The classification work is different: shadow SaaS classification is about cost, criticality, and vendor risk; shadow AI classification adds EU AI Act risk-tiering and expanded GDPR DPIA obligations on top.
Doesn't our SSO already give us this picture?
Partially. SSO captures the tools that flow through SSO. It misses tools using personal accounts, tools authenticated through "sign in with Google" with personal credentials, tools using magic-link authentication outside the federated identity layer, and tools used through paid tiers that have not been federated yet. In most mid-market firms, SSO captures roughly half of the active tool population, not all of it.
We already do annual SaaS rationalisation. Isn't that enough?
It is a good start; it is not the whole job. Annual rationalisation finds duplicates and underutilised seats at a snapshot. Continuous discovery surfaces new tools as they appear, catches the renewal-surprise pattern before the auto-renewal hits, and produces an inventory the security and compliance functions can operate against, none of which annual rationalisation does well. The two are complementary. Continuous discovery is what makes annual SaaS governance produce defensible numbers.
What is the realistic time investment to set this up?
Initial discovery: 30 days end-to-end at most mid-market firms with the right data sources connected. Catalogue cleanup and classification: another 30 days running in parallel with the discovery. Operationalising the governance pipeline - renewal reviews, vendor risk queues, DPO and AI classification passes, is a longer build, but the inventory becomes useful from day 30. Do not wait for the full pipeline to be live before using the data; the data is useful immediately.
