Shadow SaaS
also called Unsanctioned SaaS, SaaS Sprawl
Software holding company data that no central inventory records, usually acquired on a free tier or an expense card, or connected as an integration rather than purchased as an application.
Finance flags unbudgeted software spend. A survey of every team returns 112 applications. A month later an access review finds 180 applications holding company data. The 68-application gap is not people hiding things; it is the difference between what teams think of as an application and what actually holds data.
Three categories produce the gap: tools with no cost at all, which are also the least reviewed; purchases below the procurement threshold on personal or team cards; and integrations rather than applications, where an OAuth grant gives a third party read access to a system you do own, without ever appearing as a line item. A single consent granting read access to the records of 50,000 users is one click and no purchase order.
Why it matters
The risk does not scale with spend. A free browser extension with read access to the customer record system is a larger exposure than a £40,000 design tool, and the spend-based view ranks them the other way round. Access is the right axis, and access is visible in a feed the organisation already has.
The second reason is regulatory. A processor you cannot name is a processor you have not assessed, contracted or notified, and the question "list every third party that processes personal data" has a definite answer that a survey cannot produce.
Implementation patterns
- Build from feeds that work without cooperation, in descending yield: identity provider applications and OAuth consents with scopes and last-use dates; expense and card transactions by merchant; egress or DNS telemetry from managed devices; third-party app and extension inventories on the platforms you run.
- Treat the identity feed as primary. It names the application and the data it can reach in one record, and last-use dates give you the retirement list for free.
- Make the register self-maintaining. A new grant or a new recurring merchant creates a record automatically, with the owner derived from the granting user.
- Triage by data reached, not cost, and set review thresholds on scope rather than on price.
- Publish two or three sanctioned options per category and make them easier to obtain than the alternative. Unsanctioned adoption is usually a response to a procurement process measured in weeks.
- Review grants for departed users and dormant applications quarterly. Revoking an unused grant is the cheapest risk reduction available and needs no negotiation with anyone.
- Keep the survey for one purpose: it is the only source that explains why a tool was adopted, which is what you need to replace it.
Industry example
The mechanism is best documented in the platform vendors' own controls: major productivity suites now require administrator consent for third-party applications requesting sensitive scopes precisely because user consent proved to be the dominant path for data leaving an organisation, and OAuth consent phishing is a recognised attack technique in published threat frameworks. The lesson for an estate owner is that the grant log is the inventory, and the control point is the consent policy rather than a procurement rule. MITRE ATT&CK carries the abuse of application access tokens as an established technique, which is the evidence to use when a procurement-led answer is proposed. The obligation side is older and dated: since the GDPR took effect in 2018, a processor you cannot name is a processor you have not assessed, contracted or disclosed.
Failure scenarios
- A free-tier integration retaining customer data after the team that connected it has been reorganised away, with no contract and no named owner.
- A departed employee's personal account still holding a live grant, because offboarding covered systems in the inventory and the grant was not in it.
- A subprocessor nobody declared, discovered during a customer security questionnaire or an audit.
- A ban that moves the problem, pushing adoption onto personal devices and accounts where there is no telemetry at all.
- Annual reconciliation, which produces a snapshot that is wrong within weeks and a false sense of coverage.
Trade-offs
Feed-based discovery costs engineering work and creates a register someone must triage, which is real effort with no visible output on a good day. It also surfaces uncomfortable volumes: the first run typically finds several times what anyone expected, and the organisation must then decide what to do about tools people depend on. The alternative is cheaper and leaves the question unanswerable, which is tolerable until a regulator, a customer questionnaire or an incident asks it.
When not to use it
A 40-person company does not need telemetry pipelines; one person with the card statement and the identity provider's application list has a complete picture in an afternoon. The machinery earns its cost once the application count exceeds what one person can hold, roughly a few hundred, or once an external party will ask for the register. And discovery without a sanctioned alternative is wasted: a register of tools you intend to ban produces evasion rather than consolidation.
Interview question
Q: A customer's security questionnaire asks you to list every third party that can access their data. You know the official list is incomplete. How would you produce a defensible answer in two weeks, and what would you put in place so the answer stays true?
What a strong answer covers: feeds over surveys, with the identity provider's grant log as the primary source and the reason it dominates · the three invisible categories and why free tiers are the highest risk · building the register from events rather than from a periodic exercise, with ownership derived automatically · triage by scope rather than cost · the consent policy as the control point, not the procurement rule · and honesty about the limits of the two-week answer, including what the feeds cannot see and how that gap is stated to the customer.
Quick check
Quiz: Why does an OAuth grant represent a larger exposure than a comparable paid application? — Because it reaches data inside a system you already own, with scopes the user chose, and it never appears in procurement or finance records, so it is unassessed and unowned.
Flashcard: Which single feed closes most of the shadow-SaaS gap, and what does it give you beyond names? — The identity provider's application and OAuth consent log: it names the data each application can reach, plus last-use dates that produce the retirement list.