Skip to content
Asset Register

Register  ·  Foundations

The Inventory Problem

Every organisation that measures for the first time finds several times more applications than expected. Building the register takes weeks.

Procedure  ·  757 words

Ask an IT director how many SaaS applications the organisation uses. The answer is usually confident and usually wrong by a factor of three or more.

Why the count is always low

Departmental purchases made on cards, never routed through IT.

Free tiers that never appear in any financial system.

Applications inherited through acquisitions.

Tools acquired for a project and never retired.

Personal accounts used for work, which are invisible to everything and hold company data.

Applications behind applications: an integration, a plugin, a connected app granted access by a user.

Building the register

Start from the sources that see the most, in this order:

Identity provider. Every application behind single sign-on, with usage. Cleanest data available and it misses everything not federated.

Expense and card data. Every recurring charge. Catches what SSO misses and misses free tiers entirely.

Endpoint and browser telemetry, where you have it. Sees what people actually open.

OAuth grants in your major platforms. Shows which third-party applications have been granted access to your email, files and calendars. This source finds things nothing else does and is the one most often skipped.

Ask people. A short survey per team: what do you use, what do you pay for, who set it up. Crude, and it finds things no automated source sees.

Then reconcile, which is the hard part and has its own note.

The fields that matter

Per application, minimally:

Name, vendor, and what it does in one line.

Business owner — a named person, not a department.

Technical owner, where different.

Status: in use, being retired, unapproved, under review.

Users, count and preferably a list.

Cost, annual, and the contract term.

Renewal date and notice period.

Data classification: what sensitivity of data is in it.

How it authenticates: SSO, local passwords, shared account.

Discovery source, so you know how you learned about it.

Ten fields. They fit in a spreadsheet and they answer most questions asked of a SaaS programme.

What the first pass reveals

Consistently:

Duplicate tools. Three project trackers, two video platforms, four file-sharing services.

Applications nobody owns. The person who set it up left.

Applications nobody uses, still billing.

Applications holding sensitive data with no security review.

Shared accounts, with a password in a document.

Personal accounts used for company work.

Each of those is a finding worth acting on and each is invisible without the register.

Keeping it current

The register decays faster than a hardware one, because new applications appear weekly.

Re-run discovery monthly, automatically where possible.

Alert on new applications appearing in expense data or in OAuth grants.

Review quarterly with owners: still needed, still this many seats, still this classification.

Reconcile against reality annually, by asking teams rather than by reading the tool.

Assign the register an owner. An unowned register is out of date within two quarters, and then it is worse than none because people trust it.

The survey that finds what tools cannot

Automated discovery misses free tiers and personal accounts entirely. A short survey finds them, once, if it is framed correctly.

Five questions per team: what do you use daily, what do you pay for, what did you sign up for and stop using, what holds customer or employee data, and what would stop you working if it disappeared tomorrow.

State the amnesty explicitly and in writing: declaring an existing tool has no consequence, and the purpose is to protect the data rather than to find fault.

Send it to team leads, not to everyone. Higher response rate and better answers.

Give a deadline of a week and chase once.

Expect the last question to be the most useful. "What would stop you working" identifies the load-bearing shadow applications, which are exactly the ones that need a continuity plan and a security look.

The number to report first

Discovery produces a large list, and how it is first presented determines whether it reads as a crisis or as work.

Do not lead with the total count. Two hundred applications sounds like a failure of control and provokes a defensive response.

Lead with the gap: what we knew about, what exists, and the difference.

Tier immediately: how many hold no company data, how many hold business data, how many hold sensitive data. The third number is usually small and it is the one that matters.

Attach one concrete finding — a duplicate, an unused subscription, an orphaned account.

Say what you cannot see, because a figure presented as complete will be undermined by the first person who names a missing application.