Here’s a question I ask at almost every company I work with: Can you give me a list of every software application your company is currently paying for?
The answer is almost always some variation of “…probably?” followed by a long pause.
That pause is the problem.
Most small and medium-sized businesses are running on a foundation of software they can’t fully see — tools bought on credit cards, free trials that turned into paid subscriptions, department-specific apps that IT never heard about, and legacy platforms no one remembers signing up for but everyone is afraid to cancel. It’s not a sign of a badly run company. It’s the natural result of growth without guardrails.
But here’s the thing: what you can’t see, you can’t secure. And you can’t manage what you don’t know you have.
That’s where a software catalog comes in.
What Is a Software Catalog?
A software catalog (sometimes called a software inventory or application portfolio) is exactly what it sounds like: a centralized, maintained list of every software application your business uses, pays for, or has access to.
At its most basic, it answers three questions:
- What software do we have?
- Who owns it and who uses it?
- What does it cost?
At its most powerful, it becomes the backbone of your security posture, your procurement process, your vendor management strategy, and your IT roadmap. But we’ll get there. Start with the list.
Why Most SMBs Don’t Have One (And Why That’s Understandable)
Building a software catalog sounds boring. It is, a little. It doesn’t feel urgent the way a server outage feels urgent, or exciting the way a new product launch feels exciting. So it gets deprioritized indefinitely — right up until the moment it becomes a crisis.
At one of my former companies, I inherited an environment with no software approval process and no purchasing controls whatsoever. People were buying tools on personal credit cards, expensing them, and neither IT nor Finance had any consolidated view of what was being paid for. When I finally pulled the full picture together — combing through accounting systems, department budgets, and credit card receipts — we had over 250 applications.
Two hundred and fifty.
About a third of the software budget was going to research tools. Only around two-thirds of what we had was managed by IT. The other third? Completely unmanaged. Which, as I’ll explain in a moment, is not a neutral state of affairs.
If your company has more than a handful of employees, I’d be willing to bet your number is higher than you think.
The Security Case for a Software Catalog
Here’s where it gets serious.
Unmanaged software isn’t just a budget problem — it’s a security risk. When software is purchased and operated outside of IT’s oversight, a few things tend to happen:
No one is watching it. Security patches don’t get applied. Configuration best practices don’t get followed. When a vulnerability is disclosed, no one knows the tool exists, so no one responds.
Access doesn’t get cleaned up. This is the one that keeps me up at night. When an employee leaves and their departure is managed through HR and IT working together, their access gets revoked. But software that IT doesn’t know about? That offboarding step never happens. I have seen former employees — people who had been gone for years — still holding active licenses and login access to company systems. That’s not a hypothetical risk. That’s an open door.
Data governance becomes impossible. Many SaaS tools store company data — files, contacts, communications, customer information. When those tools are invisible to IT, you have no idea where your data is, who has access to it, or whether it’s being handled in compliance with your legal and regulatory obligations.
For businesses subject to compliance frameworks — HIPAA, CMMC, SOC 2, GDPR, or others — a software catalog isn’t optional. It’s foundational. Regulators want to know what systems you have. You should too.
How to Build One (Without Losing Your Mind)
The good news: you don’t need enterprise software to start. A spreadsheet will do for now.
Step 1: Cast a wide net. Don’t rely on IT’s knowledge alone. Go to Finance and pull every software-related line item from the last 12 months — credit card receipts, invoices, recurring charges. Ask department heads what tools their teams use. You’ll be surprised what surfaces.
Step 2: For each application, capture the basics. At minimum: application name, vendor, what it does, who owns it (the business owner, not just the IT admin), how many licenses you have, what it costs annually, and when the contract renews.
Step 3: Identify who has access. This is the labor-intensive part, but it’s critical. For each tool, get a list of current users and cross-reference it against your active employee roster. Anyone on the software list who isn’t on the employee list is a problem to fix immediately.
Step 4: Put procurement controls in place. A software catalog is only useful if it stays current. That means new software purchases need to flow through a process — a request, an approval, IT awareness, and a record in the catalog. This doesn’t have to be bureaucratic. It just has to exist.
Step 5: Assign ownership. Every application should have a named business owner who is responsible for decisions about it: renew or cancel, add users or remove them, evaluate alternatives. IT can manage the catalog, but business owners make the calls.
Connecting the Catalog to Offboarding
Once you have a catalog, offboarding becomes something you can actually do completely.
The typical offboarding checklist covers the obvious things: return the laptop, revoke email access, disable the VPN. But most companies stop there. The catalog gives you the full picture.
When someone leaves, you can now run down every application they had access to — not just the ones IT manages, but everything — and make sure access is revoked and licenses are reclaimed. That’s the difference between a partially closed door and a properly closed one.
Ideally, this process is automated. Tools like Okta can be connected to your software catalog and your HR system so that when an employee is marked as terminated, deprovisioning kicks off automatically across connected applications. But even if you’re doing it manually, having the catalog means you’re doing it completely rather than guessing.
A Note on What Comes Next
A software catalog is a starting point, not a finish line.
Once you know what you have, you can start asking harder questions: Do we need all of this? Are we paying for duplicate functionality? Are there tools we should retire, replace, or consolidate? What’s the plan for getting from where we are to where we want to be — and in what order, with what dependencies?
That’s where the catalog becomes an IT roadmap. Knowing your contract end dates, your integrations, your service accounts, and your user dependencies means you can plan software transitions intelligently rather than reactively. You can retire a tool on your own timeline, fully understanding what it’s connected to and what needs to happen before you can safely shut it off.
That’s a topic for another post. But it all starts here — with knowing what you have.
The Bottom Line
A software catalog won’t show up on anyone’s highlight reel. It’s not a flashy initiative. But it’s the kind of foundational work that makes everything else possible — security, compliance, cost management, offboarding, and long-term IT strategy.
If you don’t have one, this week is a good time to start.
And if the audit turns up more than 250 applications? Don’t say I didn’t warn you.
Questions about where to start with your software catalog or IT security fundamentals? Feel free to reach out.
