Finance flags £2.1M of unbudgeted software spend. You run a survey asking teams to declare the tools they use and get 96 responses covering 112 applications. A month later an access review turns up 180 applications holding company data that were not on the list. Why did the survey fail, and what produces a true inventory?

The first three things to look at

1. Who answered the survey. Respondents declare what they think of as applications: the things with a procurement process. Nobody lists the browser extension that reads the CRM, the free analytics tier someone connected in 2023, or the AI tool a team trialled last month.
2. What the access review saw that the survey did not. The review found applications by looking at authorisation grants, which is evidence rather than recollection.
3. Which feeds already exist and are unread. Almost every organisation has three sources of truth about this and reads none of them.

The diagnosis

A survey measures awareness, not usage, and the gap between the two is the definition of shadow IT. Asking is also self-defeating where the spend is on a personal card or a free tier, because the respondent does not experience it as procurement.

The 68-application gap is not people hiding things. It is three categories the survey cannot see: tools with no cost (free tiers, which are the highest-risk category because they are also the least reviewed), tools bought below the procurement threshold on expense, and integrations rather than applications — OAuth grants into systems you do own, which hold data without ever appearing as a line item.

The fix

Build the inventory from feeds that exist whether or not anyone cooperates, in this order of yield:

• Identity provider grants. Every single sign-on application and every OAuth consent, with the scopes granted and the date of last use. This is the highest-value feed by a wide margin, because it names the application and the data it can reach. Last-use dates also give you the retirement list for free.
• Expense and card transactions, categorised by merchant. Catches everything bought below the procurement threshold, which is most of the tail.
• Egress or DNS telemetry from managed devices and networks, which catches tools that use neither single sign-on nor a company card.
• Browser extension and third-party app inventories for the major platforms you run, which is where the data-access risk concentrates.

Then make the inventory self-maintaining rather than periodic: a new OAuth grant or a new recurring merchant creates a record automatically with an owner derived from the granting user. A quarterly reconciliation exercise produces a snapshot that is wrong within weeks; a feed produces a register.

What to do with the result

Do not start with a ban. Triage by data reached, not by cost: an application with read access to customer records is a different problem from a £9-a-month design tool. Publish the two or three sanctioned options in each category and make them easier to get than the alternative, because unsanctioned tools are usually a response to a procurement process measured in weeks.

When this is over-engineering

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 number of applications exceeds what one person can hold, roughly a few hundred, or once a regulator will ask you for the register. And the survey is not worthless — it is the only feed that tells you why a tool was adopted, which is the information you need to replace it.