Ask an IT manager how many cloud applications their organisation uses and the answer is usually somewhere between thirty and forty. Run a discovery exercise and the number comes back between 130 and 342. That gap is not a failure of record-keeping. It is the predictable result of a decade in which software became something any department can buy with a card, and roughly 56% of software decisions moved outside IT entirely.
The gap matters more than it used to, for two reasons. Under GDPR, every unsanctioned application processing personal data without a data processing agreement is a live compliance breach rather than a theoretical one. And shadow AI has changed the speed at which data leaves: a SaaS tool needs someone to sign up, integrate and upload, while a generative AI prompt needs a browser tab and a paste.
This guide covers how to find what is actually running, using tools you already own; what to do with the list afterwards, which is where most discovery projects die; and how to run the exercise in a way that satisfies European works councils rather than provoking them.
The size of the gap
| Measure | Figure | Source type |
|---|---|---|
| Applications IT believes are in use | 30 – 40 | Vendor telemetry |
| Applications actually in use | 130 – 342 | SaaS management research |
| Software purchases made outside IT | 56% of the footprint | Industry survey |
| SaaS spend owned by business lines | ~70% (IT controls ~26%) | SaaS management index |
| Provisioned licences sitting idle | 44% – 53% | SaaS management research |
| Employees admitting unsanctioned use | ~80% of knowledge workers | Vendor survey |
Two things follow from that table, and the second is the one that gets budget approved. The security exposure is obvious. Less obvious is that roughly half of what you already pay for is unused — which means a discovery exercise pitched purely as a security project is leaving its strongest argument on the table.
It is also worth being precise about motive. The research consistently shows this is an adoption problem rather than a discipline problem: staff reach for unsanctioned tools because the sanctioned one is slow to log into, lacks a specific feature, or because procurement takes six weeks and the deadline is Thursday. That matters for what you do after discovery, because a control that does not address the friction simply relocates the behaviour.
Shadow AI is a different problem
Shadow AI deserves separate treatment because the exposure mechanism differs. Traditional shadow IT leaks at the file layer: someone uploads a document to an unmanaged cloud drive, which file-based data loss prevention is built to catch. Shadow AI leaks at the prompt layer: someone pastes a block of text into a browser form, which regex-and-file-based tooling frequently misses entirely.
The numbers, and note which are vendor telemetry rather than independent research:
- Around 75% of knowledge workers report using AI at work, and roughly 78% bring their own tools rather than a sanctioned one (vendor-published workplace survey).
- Studies of pasted content put sensitive enterprise data at somewhere between 11% and 39.7% of prompt text — a wide range that reflects different measurement methods, so treat it as a signal rather than a statistic (vendor endpoint telemetry).
- The great majority of consumer AI access happens through personal rather than corporate accounts, which means no enterprise data-handling terms apply and prompts may be retained for training (vendor telemetry).
- Source code is consistently the largest single category of exposed data, ahead of customer personal data and credentials (vendor telemetry).
- IBM’s breach cost research attributes an additional ≈€615,000 ($670,000) to breaches involving shadow AI (independent research).
Converted from USD at ≈€0.92 per US dollar (August 2026).
A newer wrinkle is worth flagging: surveys of enterprise AI agent usage report that a large majority of organisations discovered autonomous agents running that they did not know about — often in organisations whose security leads had been confident they had visibility. Agents hold persistent API credentials and cross-system permissions, so an unmonitored one is a standing privileged identity. We covered the data exposure side of this in shadow AI and data leakage.
Eight ways to find it, ranked by what you already own
| Method | Finds | Misses | Effort | Already own it? |
|---|---|---|---|---|
| Identity provider and OAuth grant review | SSO logins and third-party apps granted API access to your tenant | Apps used with personal accounts | Low | Yes — Entra ID / Google Workspace |
| DNS query log analysis | Every SaaS domain resolved on the network | Encrypted DNS, cellular traffic, specific URLs | Low | Yes — DNS servers |
| Financial and expense audit | Paid subscriptions on cards and invoices | Free tiers, most shadow AI | Medium | Yes — finance systems |
| Secure web gateway / proxy logs | Full URLs, uploads, user identity, volumes | Devices off-network without an agent | Medium | Yes, if you run an SWG |
| Firewall and NetFlow egress | Traffic volumes and destination ranges | App names behind shared CDNs | Low–medium | Yes — edge firewalls |
| CASB API integration | Apps connected to your sanctioned suites, external sharing | Standalone web SaaS with no tenant link | Medium | Partly — higher suite tiers |
| Endpoint software inventory | Installed clients and browser extensions | Pure browser-based use | Medium–high | Yes — endpoint protection suite |
| Anonymous staff survey | Why they use it, personal-device habits | Precise quantitative data | Low | Yes — any form tool |
No single method is sufficient, but the ordering above is deliberate. If you have one afternoon, start with the OAuth grant review: it takes under an hour, requires nothing you do not already have, and surfaces the highest-risk category — applications with standing API access to corporate mail and files. Then add DNS logs for breadth and a finance query for the paid tail. Those three together get most mid-market organisations to a defensible first inventory.
Two coverage caveats to state plainly in your report. Network-based methods see managed devices on the network; they do not see a laptop on a home connection or a phone on cellular data, which is where blocked activity migrates. And DNS shows the domain, not what was sent to it — for that you need gateway-level visibility, which we describe in our guide to what a secure web gateway does, alongside DNS filtering for the mid-market.
The OAuth blind spot
This is the part that surprises people, so it is worth walking through the mechanism.
An employee signs up for a tool and clicks “Sign in with Microsoft”. The application requests permission scopes — reading mail, reading and writing files, offline access. The employee accepts. The application receives a refresh token and from that moment communicates directly with your tenant’s API, cloud to cloud. That traffic never crosses your network, so your firewall, DNS filter and secure web gateway see nothing at all. The access persists through password changes and survives multi-factor authentication challenges, because the consent was granted once and the token keeps working.
The practical result: an application nobody procured has continuous read access to a mailbox, and none of your perimeter controls can see it. This is the single strongest argument for making the identity provider your primary discovery surface rather than the network.
Reviewing it is straightforward. In Microsoft Entra, open Enterprise Applications and filter for user-consented applications, then examine the granted permissions per app — mail read access, broad file access and directory read access are the scopes worth flagging first. Revoke what you do not recognise, and consider switching user consent off so future third-party requests route through an administrator. In Google Workspace the equivalent sits under Security, then access and data control, then API controls, where you can review third-party app access, block what fails review and restrict unverified apps by organisational unit.
One caution: revoking an app that a team genuinely depends on, without warning, converts a security exercise into a support incident and an internal political problem. Review first, then decide, then revoke — in that order.
What to do with the list
Discovery produces hundreds of entries and the instinct is to block everything, which is exactly how these projects fail. Sort each finding into one of four outcomes based on data sensitivity, how many people depend on it and whether an approved alternative exists.
| Outcome | When | What you actually do |
|---|---|---|
| Sanction and manage | Real business value, broad adoption, acceptable risk | Vendor assessment, signed data processing agreement, single sign-on and MFA, named owner, consolidated billing |
| Tolerate with controls | Niche utility, small user base, no approved equivalent | Documented usage limits, gateway policy blocking uploads of sensitive data, no personal data permitted, quarterly review |
| Replace | Duplicates something you already pay for | Migration window of about 30 days, export and import support, in-app guidance — then retire |
| Block and enforce | High compliance risk, personal data with no agreement, or genuinely malicious | Domain block, OAuth grants revoked, and a block page explaining why with a link to the approved alternative |
The evidence on blanket blocking is unambiguous and worth putting in front of anyone who wants to skip the triage. Blocking without offering a functional alternative does not remove the need that drove the adoption; it pushes the work onto personal phones, home computers and cellular hotspots, where you have no visibility, no gateway inspection and no logging. You have not eliminated the exposure, you have made it invisible — which is a worse position than the one you started in.
For tools in the “tolerate” and “sanction” categories, gateway-level controls are what make the outcome real rather than aspirational: inspecting what is uploaded, blocking sensitive content in prompts and forms, and applying policy per application rather than per domain. That is the ground covered by data loss prevention in SASE and CASB in a unified platform.
The European layer: compliance and works councils
Two regulatory forces pull in opposite directions here, and you need both in the plan.
The obligation to know. Under GDPR article 28, using a processor without a data processing agreement is a breach from the moment personal data reaches it. Article 30 requires records of processing activities, which are inaccurate by definition if unknown tools process personal data. Article 32 requires appropriate technical measures, which unmanaged tools without SSO or MFA do not meet. Exposure runs to €20 million or 4% of global turnover. NIS2 adds asset management and supply chain obligations on top: an organisation that cannot enumerate its cloud services cannot demonstrate either.
The limits on how you may look. In Belgium, monitoring of electronic communications at work is governed by Collective Labour Agreement 81, with comparable rules across Germany, France and the Netherlands. It does not prohibit discovery; it regulates the method, and three principles decide whether your programme is lawful:
- Legitimate purpose. Network security, threat prevention and demonstrable GDPR compliance qualify. General curiosity about employee behaviour does not.
- Prior transparency. A written policy stating what is logged, how long it is retained and how investigations proceed, published before monitoring starts.
- Proportionality through two tiers. Work with aggregated, non-identified traffic data first. De-anonymise an individual’s records only after aggregate analysis surfaces a genuine anomaly, following a documented procedure.
Submit the design to your works council or prevention committee for consultation before you begin. Teams that do this find the conversation far easier than expected, because the two-tier structure is precisely what representatives want to hear: you are counting applications, not watching people.
The objections, and where they are right
“We already block unknown domains at the firewall.” Partly effective and structurally incomplete. Perimeter filtering only sees managed devices on your network or VPN, so remote and hybrid staff bypass it by default. Most shadow SaaS sits on reputable domains in permitted categories, so it is not blocked anyway. And OAuth traffic never touches your perimeter at all.
“Our people are trusted professionals with annual training.” Both things are true simultaneously: they are trustworthy, and around 80% of knowledge workers still use unsanctioned tools. Training informs people of policy; it does not resolve the conflict between policy and a deadline. Treating this as a behavioural failure leads to controls that punish rather than enable, which produces the circumvention described above.
“Discovery just produces a list nobody has time to act on.” The most honest objection on the list, and the reason to run triage from day one rather than as a second project. A structured framework concentrates effort on the 15% to 20% of findings that carry most of the risk; the long tail of one-user utilities can be recorded and left alone. Automating the routine parts — high-risk OAuth grants and known AI domains handled by identity and gateway policy — keeps manual work for the departmental tools that genuinely need a decision.
“This is surveillance and the works council will object.” A legitimate constraint, not an obstacle, and one where the objection is right about the risk if you get the method wrong. Aggregate-first monitoring with prior notification and consultation is both lawful and, in practice, uncontroversial. What draws opposition is per-employee monitoring introduced without notice.
Start with one hour in your identity provider
Open your tenant’s enterprise applications, filter for user-consented apps, and look at what has been granted access to corporate mail and files. Most organisations find something in that list they did not know existed, and the exercise costs an afternoon rather than a budget cycle. Then add DNS logs and a finance query, and you have a first inventory worth taking to management — framed around unused licence spend and GDPR exposure rather than employee behaviour.
What that inventory usually reveals is that the controls needed afterwards live in the same place: visibility over what leaves the organisation, policy per application rather than per domain, and inspection that catches a paste into a prompt box as well as a file upload. Jimber delivers secure web gateway, DNS filtering, cloud application control and data loss prevention from one EU-sovereign platform, which means the discovery you run and the controls you apply afterwards share a single policy layer — and one set of logs your works council agreement can actually describe. Book a demo and bring your first discovery list; we will work through the triage with you.
Frequently asked questions
How do I discover shadow IT without buying tools?
Three methods use infrastructure you already own. Review third-party OAuth grants and sign-in logs in Microsoft Entra ID or Google Workspace, analyse DNS query logs from your resolvers, and run a keyword query across corporate card and invoice data with finance. Combined, these surface the majority of active unmanaged applications.
What is the difference between shadow IT and shadow AI?
Shadow IT is any unapproved software or cloud service introduced without IT authorisation. Shadow AI is the subset involving unsanctioned AI tools, usually through personal accounts. The exposure mechanism differs: shadow IT typically leaks through file uploads, while shadow AI leaks through text pasted into prompt boxes, which file-based controls often miss.
Why does blanket blocking of shadow IT fail?
Because it addresses the symptom rather than the need. When a tool is blocked without a working alternative, staff move the task to a personal phone, home computer or cellular connection. The underlying data exposure continues, but now outside your gateway, your logging and your endpoint controls — a worse position than visible shadow IT.
How does shadow IT affect GDPR compliance?
An unsanctioned application processing personal data without a signed data processing agreement breaches article 28 from the moment data reaches it. It also invalidates your article 30 records of processing and undermines article 32 security requirements. Maximum exposure is €20 million or 4% of global annual turnover.
What is an OAuth consent grant risk?
When a user approves “Sign in with Microsoft” for a third-party app, that app receives a token allowing direct API access to tenant data such as mail, files and calendars. The traffic runs cloud to cloud, bypassing your network controls entirely, and access persists through password resets until an administrator revokes the grant.
How do European labour laws affect shadow IT monitoring?
They regulate the method rather than prohibiting it. In Belgium, Collective Labour Agreement 81 requires a legitimate purpose, a written policy communicated before monitoring starts, and works council consultation. Analysis should begin with aggregated, non-identified data, with individual records examined only after a documented anomaly.
How do we find SaaS that never appears on an expense report?
Free tiers and personal-account AI use generate no financial trail, so combine DNS query analysis with an identity provider OAuth review. DNS shows which services are being reached from the network; the identity provider shows which applications were authorised using corporate credentials, including tools nobody ever paid for.
What do we do about a shadow tool a whole department depends on?
Route it to sanction and manage rather than blocking it. Run a vendor risk assessment, sign a data processing agreement, bring it under single sign-on with multi-factor authentication, assign an owner and move billing to a corporate account. This formalises oversight without disrupting a team that has already proven the tool’s value.
