MELLORCATalk to Mellorca
Discovery›SaaS & Application Portfolio Management
SaaS & Application Portfolio Management · Discovery

Why Businesses Cannot Produce a Complete List of the Applications They Use

When software is bought by departments, charged to cards, introduced through projects and retained after owners move on, the application estate can grow faster than the organisation's ability to see and govern it.

Mellorca Discovery·SaaS & Application Portfolio Management·3 September 2026

The problem in plain language

Finance can list vendors, identity teams can list some connected applications and IT can list systems it manages, yet nobody can reconcile those views into one dependable application portfolio.

The gap usually surfaces when someone asks a simple question. Which tools hold customer data? What will we stop paying for if we retire this platform? Which applications does a departing employee still have access to? Each question triggers a fresh exercise: exporting supplier lists, emailing department heads and comparing spreadsheets. The answer is assembled for the occasion and starts going out of date as soon as it is finished.

What the buyer is actually trying to solve

Searches such as "application inventory", "SaaS inventory", "software asset discovery", "shadow IT inventory" and "application portfolio management" reflect a need to know what exists before the business can govern, secure, rationalise or retire it.

Behind those searches are practical triggers: a renewal that nobody can justify, a security questionnaire that asks for a list of systems processing personal data, a migration that needs to know every integration, or a cost review that has found overlapping subscriptions. The buyer is rarely looking for a list for its own sake. They need a dependable basis for decisions.

Evidence and system mechanism

NIST Cybersecurity Framework 2.0 includes maintaining inventories of software, services and systems managed by the organisation, and separately inventories of services provided by suppliers, which is where externally hosted applications usually sit. NIST software-asset guidance also treats accurate software inventory as foundational to policy, licence and security decisions. Its Software Identification project states that knowing what software is installed and used can help an enterprise avoid paying for unneeded licences, and links inventory to patching, configuration and attack-surface reduction. NIST's security measures for critical software similarly begin with establishing and maintaining a software inventory.

The CIS Critical Security Controls take the same position. Control 2 calls for organisations to actively inventory, track and correct all software on the network so that only authorised software is installed and can run, and unmanaged software is found.

The mechanism is straightforward: if acquisition and retirement events do not update a governed inventory, the list becomes a periodic survey rather than an operational record.

Each data source sees only part of the estate. Finance sees what is paid for, not who uses it or what it connects to. Single sign-on sees applications configured for it, not tools people log into with a separate password. Endpoint management sees installed software, not browser-based services. Procurement sees what went through procurement. The portfolio exists only where those views are combined, and most organisations have no process that combines them continuously.

Problem owner and why now

The CIO office, enterprise architecture and IT operations typically share ownership. The CIO and CFO become budget owners because incomplete visibility affects renewal decisions, duplication, security and cost. Budget reductions or application-rationalisation programmes make the problem urgent.

Other common triggers include a merger or acquisition that brings a second application estate, a security incident involving a tool nobody knew was in use, an audit or customer due-diligence request, and a move to a new identity platform that requires every application to be connected.

Economic consequence

Unknown applications can create duplicate capability, licence waste, unmanaged integrations, unsupported dependencies and security gaps. The business may also pay to discover its own estate repeatedly during audits, migrations and transformation programmes.

The cost is not only the subscriptions themselves. When ownership is unclear, renewals proceed by default because nobody has the authority or information to cancel. When integrations are unknown, retiring one system can break a process elsewhere. When data locations are unknown, responding to a data-subject request or a breach takes longer and carries more uncertainty. Mellorca's Impact article on unused software licences shows how to model one part of this exposure with your own figures.

Do not apply a generic percentage. Measure the number of applications found in each source, the share without a named owner, and the recurring spend that cannot be traced to a current business purpose.

Root cause

Distributed purchasing, expense-card subscriptions, project-specific tools, weak ownership transfer, missing retirement processes and disconnected identity, finance and IT data all contribute to incomplete visibility.

It helps to separate symptom from cause. "We do not have a list" is a symptom. The causes are usually procedural: no agreed definition of what counts as an application, no step in purchasing that registers a new tool, no step in offboarding that transfers application ownership (see when application owners leave without transfer), and no retirement process that removes cost, access and integrations together.

Warning signs

  • Each audit or renewal cycle begins with a manual inventory exercise.
  • Finance holds recurring charges that no department recognises.
  • Several teams use different tools for the same capability.
  • Leavers' access is removed from known systems while other tools are found later.
  • Nobody can say which applications hold personal or customer data.

Practical intervention

  1. Define what counts as an application or external service.
  2. Combine finance, SSO, endpoint, procurement and architecture evidence.
  3. Assign business and technical owners.
  4. Capture purpose, capability, users, integrations, data and renewal dates.
  5. Make acquisition and retirement update the inventory automatically where possible.
  6. Review orphaned and overlapping applications.

Illustrative sequence, not a client case: a business exports twelve months of supplier payments, its SSO application list and its endpoint software report. It matches them by vendor name and finds three groups: applications visible in all sources, applications paid for but not connected to SSO, and applications connected but not obviously paid for. The second and third groups become the first ownership and risk review. The reconciliation is then repeated monthly, with new purchases and leavers feeding it, so the list stays current rather than being rebuilt.

Trade-offs

An inventory can become an end in itself. Capturing every attribute for every tool consumes effort that is better spent on the applications that matter. A sensible approach records a small set of fields for everything and fuller detail for applications that hold sensitive data, support critical processes or carry significant spend. Discovery tooling helps, but it does not assign owners or make retirement decisions; those remain management responsibilities.

Diagnostic questions

  • Can finance vendor data be reconciled to the application list?
  • Which applications have no active owner?
  • Which tools bypass SSO or central procurement?
  • Can the business identify duplicate capabilities?
  • Does retirement remove integrations, access and recurring cost?
  • How long would it take to list every application that holds customer data?

What good looks like

The application portfolio is a living operational record with owners, capabilities, lifecycle state, integrations, risk and commercial context—not a spreadsheet rebuilt before each renewal cycle.

Where Mellorca fits

Mellorca can perform a digital systems audit, build the application portfolio and ownership model, map overlaps and dependencies, and create a roadmap for consolidation, governance and retirement.

Commercial next step

Discovery article → application-estate diagnostic → portfolio inventory → rationalisation and architecture roadmap → implementation and managed governance.

Sources and further reading

Related Mellorca reading

Method noteThe sources establish inventory as a recognised control and management requirement. They do not establish how many unknown applications any specific organisation has.