Is an app inventory the same as the vendor list for my vendor review?

No, though they overlap. For example, your accounting firm is a vendor in your vendor list, but won’t be in your app inventory. What’s more ambiguous is a vendor portal that your users log into — that probably does belong in your app inventory.

What's the difference between an app inventory and an asset or software inventory?

An asset inventory covers hardware like laptops, servers, network gear, and a software inventory covers what's installed on that hardware. An app inventory covers everywhere your users can log in, most of which you never install.

Do I need to include consumer apps like Uber and Instacart in our app inventory, since we use them for travel?

No. Generally, those apps are only used for authentication rather than storing data, so the only thing at stake is the login. Whether users should log into a given site with their work email is an acceptable use question.

Should I include apps like Raycast, Granola, or Obsidian in my app inventory?

Yes. Locally installed apps are still in scope, and you'll find them through device management rather than your identity provider. Where the app supports it, connect its login to your identity provider.

Do I include our own product's admin console?

Yes. It has users and roles like any other app, it usually reaches customer data, and it's one of the most commonly omitted entries.

How do I find shadow IT?

Start from what you know about in your identity provider and password manager, go through what you pay for, ask each team what they use, then sanity-check against your OAuth grants. Device management catches locally installed software that never authenticates to anything you control. If you want to go further, there are discovery tools that scan email for signup confirmations, or browser extensions that track site visits.

How complete does my app inventory need to be?

As complete as you can reasonably maintain, but know it’ll never be perfect or finished. Focus first on critical apps. A rough list covering 90% of apps is more useful than a careful one covering 60%.

What should I record for each app?

At a minimum, the app's name, what kind of data it holds, how users log into it, and who owns it. Add where the app's user list lives if you'll be running access reviews , since it saves you finding it again every quarter. Resist adding other information unless someone has signed up to maintain them.

How long does it take to build an app inventory?

A few hours at a 25-person startup, working through your identity provider, your billing, and a short conversation with each team. Maintaining it takes more effort than building it, which is why it's worth attaching updates to things that already happen, like closing your books each month or onboarding someone.

Can I just use Okta or Google as my app inventory?

Partly. Okta shows apps someone configured, which are apps you already knew about. Google adds OAuth grants — anything a user signed into with their Google account, whether or not you set it up. Neither sees an app that was never connected to it at all.

Does the accessed apps list in Google show who has access?

It shows that a user authorized an app, sometime in the last 6 months. Treat these as an input to help identify apps you might be using, not a definitive source of truth.

Who should own the app inventory?

Usually whoever owns compliance, with input from security, IT, and finance. App owners are usually whoever pays for the app or whoever set it up, with IT as the fallback.

What if nobody owns an app?

IT is the fallback, and IT already owns your productivity apps anyway. If you can't identify anyone at all, that's worth following up on, since an app nobody will claim is often one nobody is using.

How often do I need to update my app inventory?

Continuously. Use events that already happen as the trigger: new subscription charges, new hires, offboarding, and access reviews. Schedule a review of the whole list on top of that, since events only tell you about the apps they touch.

Do I need a tool to build an app inventory?

No. A spreadsheet with one row per app is enough for a first inventory, or use your compliance tool if it already has somewhere to record this.

Do we need a SaaS management platform or a CASB to build an app inventory?

If you're a small company building your first one, almost certainly not. Neither tool is really aimed at this: SaaS management platforms started in license and cost management and have moved toward checking how your apps are configured, and CASBs were built to keep data out of places it shouldn't go. Both depend on an integration catalog, so the long tail of apps you're trying to find won't be in it, and neither one substitutes for knowing your apps, sorting them by how much they matter, and locking down the critical ones.

Where do I get the list of who's actually in each app?

From the app's own admin console or API, as part of a user access review. Your identity provider knows who can authenticate, not necessarily who holds an account or what role they have.

We don’t have an app inventory and our audit is in a few weeks. What do we do?

Pull what’s in your identity provider and password manager, look at subscriptions, ask each team what they use, and add your environments and internal consoles. Mark whatever holds customer data or touches production. That should get you in a good place for your access reviews while you fill in the rest.

Building an app inventory

An app inventory is a list of everywhere users can log into in your environment. Use it for onboarding and offboarding, and to scope user access reviews.

Last updated August 2026

What is an app inventory?

An app inventory is a record of what applications your company uses to run. It’s a list of every place that holds information related to your company that a user might log into in your environment, including apps, systems, services, and internal tools. This app inventory feeds into other access processes, like onboarding, offboarding, and user access reviews; as well as things you need for compliance like vendor security reviews.

At a minimum, your app inventory should hold for each app: the app's name, what kind of data the app holds, how users log into it, and who owns it.

You need to construct your company’s app inventory because it doesn’t exist naturally — your identity provider will have a list of apps that it knows about, but there will always be shadow IT that you don't know about. That includes accounts with basic authentication using a username and password that aren’t behind single sign-on, accounts that use a different authentication system, or accounts that are tied to a personal email or passkey. But these apps should still be included in the app inventory, and they're what makes it hard to develop and maintain a comprehensive one.

What counts as an app?

For the purposes of an app inventory, an app is anything a user logs into that holds information about your business. That's broader than just SaaS tools, and includes:

SaaS apps. This is still likely the bulk of your app inventory, and most of what this guide is about.
Corporate apps. IT management apps that might automatically enroll users, even if users rarely log into them directly, like CrowdStrike or Tailscale.
Your production environment, including infrastructure providers like AWS or GCP, and your code repository and CI systems. These are usually the most sensitive systems you have.
Your own product's admin console. These are internal tools your team uses to provide support to, debug, or report on customer accounts.
Locally installed apps. Apps installed locally like Raycast, Granola, and Obsidian which can sometimes be tied to an identity provider.
Apps tied to individual identities rather than employee identities. Some apps explicitly don’t support corporate logins, since they’re meant to be tied to a named person, not an employee, like Gusto or other HR systems, Mercury, or Carta.
Apps with delegated access. Anything holding a credential that lets it act on a user's behalf or with a service account, including OAuth grants, integrations, connectors, and MCP servers.

The test for whether something belongs in the app inventory is whether it holds information about your business that isn't public. Some apps used by your company are only for authentication, and aren’t necessarily associated with your company at all: like an employee using and expensing Uber or Instacart with their corporate email, or a marketing team buying stock photos from a stock photo website. These are the lowest risk apps in your environment from a security point of view, and might not be worth an entry at all — though they may still have financial risk if you have a corporate plan. Whether a user should be logging into a given site with their work email is an acceptable use question, answered by policy rather than by your app inventory.

Don't scope this list to a particular process or framework. Build one reference list that's useful across your access processes and compliance frameworks, then take a subset of it for any particular use case.

Is my app inventory the same as my vendor list?

No, though they overlap. For example, your accounting firm is a vendor who should be in scope for a vendor security review, but they don’t have an app that your users access.

Vendor portals are more ambiguous. If some of your users have logins, it behaves like an app, so it probably belongs in your app inventory as well as your vendor list.

Why an app inventory matters beyond compliance

Compliance is the reason most people start. For SOC 2, your app inventory defines the scope of your logical access controls under CC6.1 through CC6.3. You can't show that access is authorized and reviewed without first defining what "everything" means. CIS Control 2 asks for something similar: a software inventory recording the title, publisher, business purpose, and deployment mechanism for each item in your environment. PCI DSS v4.0.1 requirement 12.5.1 requires a current inventory of in-scope system components, and ISO 27001:2022 covers this under Annex A 5.9.

Outside of compliance, an app inventory makes a lot of things easier:

Determining what a new hire needs access to on day one. Your app inventory is what keeps your onboarding checklist current. Use it to build an access matrix (which apps everyone gets, and which ones each department gets) so provisioning a new user works the same way every time. That same list tells you what to remove when someone leaves.
Answering questions about where your data lives. Customers ask which vendors touch their data, and every subprocessor list and security questionnaire response starts from knowing which apps you use and what's in them.
Determining if you're affected by a vendor breach. When a vendor discloses an issue, you can tell quickly whether you use the app and who's in it, without waiting to be notified.

How to build an app inventory

Start from what you already know. Pull the list of apps configured in your identity provider: your Okta app assignments, or the apps you've allowed to access Google Workspace data. Add the critical apps you can name without looking: source control, your cloud environments, anything holding customer data. It helps to go department by department: what's your CRM? data warehouse? CI? HRIS? VPN? and any other acronym categories you use. Also make sure to add your product's admin console.
Go through what you pay for. To get what you might have missed on the first pass, look through credit card transactions and expense reports, especially for recurring transactions. Signing up for a new vendor with a company card is fast, so this is where you find tools that never touched your identity provider.
Ask each team what they use, and who owns it. Ask users what they log into regularly, and ideally, who set it up. Doing this after reviewing billing means you can ask specific questions (and also remind your team to cancel subscriptions to apps they're no longer using). At a startup this is a short conversation per team, and while it won't scale forever, it's some of the most important context you'll get.
Note what's in each app, and how much you care about it. Roughly what data it holds, and whether it's customer data or sensitive. Keep this classification simple. At this point, you have a great first version of your app inventory; this is a reasonable place to stop if you don’t have more time. A spreadsheet is fine for your first inventory, with one row per app. Track:
1. Name, and what the app is for
2. What data it holds, and how sensitive that is
3. How users log in, via SSO, SSO plus local accounts, or username and password only
4. Who owns it, and who to ask when an access review turns up a question
Sanity-check your list against the inventories you already have. Your OAuth grants, like in Google App access control, and the shared vaults in your password manager. The OAuth grant list includes grants that are months old, and a lot of what shows up is something a user signed into or tried once and isn't still actively using. You're looking for apps you missed, so expect this to be noisy.

Putting together your first app inventory at a 25-person startup should take a few hours.

How do you find shadow IT?

The apps that are the easiest to miss are the free ones. With no charge and no SSO configuration, they leave no trace in your billing or your identity provider, so asking users is the only thing that surfaces them. Contractors and agencies bring their own tools too, so an app can end up in your environment without anyone at your company having signed up for it.

You can use device management tools to scan, enforce, or deploy locally installed software. You can also go a step further and discover apps with dedicated tools that scan your users' emails for signups, or track the sites they visit through a browser extension. At a small size, that's rarely worth it — although these are real signals, email scanning means reading across everyone's mailbox; browser extensions need close to full enrollment before the data means anything; and both are noisy.

How many apps should you expect to find?

More than you think, and more than your identity provider shows. At startup size, the joke is that every new employee gets to purchase a new tool when they join.

There's no right answer or benchmark here. You can run your infrastructure almost entirely on AWS, which counts as one app, or use a separate app for your database, transactional email, auth, and network. What matters is whether the list is complete: if billing turns up an app that wasn't on it, keep going — though you’re aiming for 90%, not 100%.

How do you keep the app inventory accurate and up-to-date?

Maintaining your app inventory means adding the apps you discover and removing the ones you no longer use. Review the list regularly and ask the same questions of each entry: does anyone still use this, how do users log into it, and who owns it now?

You maintain the list the same way you built it: using sign-on logs, new billing charges, and what teams tell you they're using. The difference is that that maintenance doesn’t necessarily need to be a separate exercise, but something that comes up naturally as part of closing your books every month, or onboarding a new user.

Working out who has what access inside each app is a separate exercise, and it's what a user access review is for.

Guidance for building an app inventory well

Enforce SSO as early as you can

The easiest way to build an app inventory is for apps to be tied to your identity provider. When users log in with their corporate accounts, you get a list of who's in your environment, a signal for which apps they actually use, and a way to revoke access. Without it, you're pulling that information from each app separately.

Enforce SSO wherever your plan allows, and treat the apps where you can't as a known gap. There's often a cost, since plenty of vendors put SSO behind an enterprise tier or don't support enforcement at all, so you can never close the gap completely. Note down the apps that don't support SSO, support SSO but not automated provisioning, or support SSO and still allow local accounts, since you'll want to check actual access to these during offboarding and user access reviews. Also watch for apps signed up with a group alias like legal@ or finance@, where the login belongs to a group rather than a person and there's no individual to attribute access to.

Also watch for credentials in your production environment that your identity provider doesn't know about, since these are what survive an offboarding. Cloud IAM is the most common source. In GCP, it's easy to grant IAM roles to personal Google accounts, because personal and corporate accounts authenticate identically through Google, so block them with domain-restricted sharing. AWS has the reverse problem, where a standalone IAM user is a long-lived credential that isn't tied to a person at all, so federate through Identity Center rather than creating them. GitHub personal access tokens and SSH public keys on your servers behave the same way, outliving access reviews and appearing in no central list. Limit direct access to production in the first place, by having users assume a scoped service account instead of holding standing access. Reaching production through a personal account then becomes a breakglass path, and can be treated like one.

Blocking new app signups at your identity provider could seem like a reasonable way to force approvals before your users adopt new apps, but this isn’t recommended. Users who need access will find another way in, and that way is one you can't see. Make SSO the easiest path available, and ask for a heads-up when someone adopts something new.

Maintain a single list

The same app inventory should serve your access reviews, vendor security reviews, onboarding, and offboarding.

Serving multiple purposes means that you need to keep what you track simple enough to maintain. If you already sort vendors by how sensitive they are, either for vendor review or because your compliance tool asks for it, use that same scheme for your app inventory instead of inventing a second one. It's also worth recording where each app's user list lives, so you aren't finding it again from scratch at your next access review. Since this will change over time, keep as a separate version the inventory you used to scope each access review.

But, consolidate only what you’re willing to maintain. Adding contract dates, renewal terms, spend, and DPAs to your app inventory can seem useful, but that turns it into vendor management. Unless someone is signing up for the work, that’ll quickly go unmaintained.

Aim for 90% coverage

Chasing completeness is what makes an app inventory impossible. It will go stale faster than you can finish it.

Focus on what matters: critical apps, like those in your production environment or holding customer data. An app inventory covering 90% of your apps badly is worth more than one covering 60% well. For the long tail, accept that you'll never get to full coverage, but still try to continually make progress.

(This is also the point where teams start shopping for a SaaS management platform or a CASB, and neither will find the apps you're missing, since both depend on an integration catalog.)

Invest the time to find app owners

Naming an owner is the least automatable work here, and yet where most of the long-term value is. The app owner is who you’ll end up asking if the app is still in use, who has access, what a role means — and who you should ask to complete an access review, instead of someone’s manager.

The difficulty is finding or delegating ownership: most business leaders don't want to own a tool, they want it to work, and would prefer IT managed it. Usually, productivity apps will be owned by IT, and department-specific apps by someone in that department (not necessarily a senior leader). If you can't find a real owner, the de facto owner is IT.

Do look out for apps which make whoever signed up first an admin of the app, even if they are not the right owner. Migrate ownership deliberately rather than discovering the problem when something breaks during user offboarding.

Use your existing inventories for discovery, not as the answer

Your identity provider, your OAuth grants, and your password manager are all inventories of a sort, and all are better at telling you an app exists and that someone may have logged into it at some point in time, than telling you if this app is actually in use in your company today.

The data is not valid for determining current access. For example, Google's list of connected apps shows every app a user authorized at some point, and a refresh token keeps working until it's revoked, until a password change on Gmail scopes, or until six months pass without use. A user who logs in specifically to delete their account leaves behind a grant that looks identical to an active one.

Discover locally installed apps on the device

Apps installed locally, like Raycast, Granola, or Obsidian, won't show up in anything tied to your identity provider, so device management is how you find them and control which ones get used. Locally installed apps can still be governed. More of these apps now have a concept of an organization and support SSO, so once you know an app is there, treat it like any other app on your list and connect its login to your identity provider.

Include delegated access between your apps

Delegated access is the newest part of shadow IT, and most teams are still working out what to do about it. When a user connects an MCP server or an agent to an app, they're granting a credential that lets one app act inside another on their behalf. You’re adding a link between apps you already have: capture information on the server, the app it reaches, and whose account it's acting as. Most apps don't surface users' delegated OAuth grants to an admin the way they do API keys, so it's hard to tell which of your apps are connected to which.

For MCP specifically, the 2026-07-28 specification formalized enterprise-managed authorization as an extension, which puts your identity provider in the middle. It's the same move as SSO versus individual usernames and passwords: an admin approves servers for the whole company, users authenticate with their corporate credentials, and access is revoked in one place. It only covers servers that require the enterprise-managed flow, in clients that support it, so it won't stop a user connecting to a server that doesn't participate. The extension is opt-in and still nascent, so support varies widely.

How app inventories usually fail

Built the first time, but never maintained. Someone puts the effort in to generate a starting app inventory, but then nobody looks at it again for a year — by which time it’s woefully out of date. You’re only slightly better off than starting from scratch.
Trying to get it perfect. An app inventory that tries to capture too much about each app, or to reach 100% coverage, is a never-ending battle. Both result in an abandoned spreadsheet.
Scoped too narrowly, to SaaS apps only. Production environments, source control, and your own product's admin console are missing — and those are the highest-risk systems you have.
Stopping with what’s in your identity provider. Your apps connected to or provisioned by your identity provider get you most of the way there — but those are the apps you already knew about. Finding the rest is the work.

FAQs

: The list of every place users can log into that holds information about your company, with the data it holds and its owner recorded for each entry. It sets the scope for your access reviews, onboarding, offboarding, and vendor security reviews.
: Anything a user logs into that holds non-public information about your business: SaaS apps, corporate IT apps, cloud and production environments, your own product's admin console, apps requiring personal logins like Carta or Gusto, and anything holding delegated access through another app.
: No, though they overlap. For example, your accounting firm is a vendor in your vendor list, but won’t be in your app inventory. What’s more ambiguous is a vendor portal that your users log into — that probably does belong in your app inventory.
: An asset inventory covers hardware like laptops, servers, network gear, and a software inventory covers what's installed on that hardware. An app inventory covers everywhere your users can log in, most of which you never install.
: No. Generally, those apps are only used for authentication rather than storing data, so the only thing at stake is the login. Whether users should log into a given site with their work email is an acceptable use question.
: Yes. Locally installed apps are still in scope, and you'll find them through device management rather than your identity provider. Where the app supports it, connect its login to your identity provider.
: Yes. It has users and roles like any other app, it usually reaches customer data, and it's one of the most commonly omitted entries.
: Start from what you know about in your identity provider and password manager, go through what you pay for, ask each team what they use, then sanity-check against your OAuth grants. Device management catches locally installed software that never authenticates to anything you control. If you want to go further, there are discovery tools that scan email for signup confirmations, or browser extensions that track site visits.
: More than you think, and more than your identity provider shows. There's no useful benchmark, because it depends on how you build: you can run your infrastructure almost entirely on AWS, which counts as one app, or use separate apps for your database, transactional email, auth, and network. At startup size, the joke is that every new employee gets to purchase a new tool when they join.
: As complete as you can reasonably maintain, but know it’ll never be perfect or finished. Focus first on critical apps. A rough list covering 90% of apps is more useful than a careful one covering 60%.
: At a minimum, the app's name, what kind of data it holds, how users log into it, and who owns it. Add where the app's user list lives if you'll be running access reviews, since it saves you finding it again every quarter. Resist adding other information unless someone has signed up to maintain them.
: A few hours at a 25-person startup, working through your identity provider, your billing, and a short conversation with each team. Maintaining it takes more effort than building it, which is why it's worth attaching updates to things that already happen, like closing your books each month or onboarding someone.
: Partly. Okta shows apps someone configured, which are apps you already knew about. Google adds OAuth grants — anything a user signed into with their Google account, whether or not you set it up. Neither sees an app that was never connected to it at all.
: It shows that a user authorized an app, sometime in the last 6 months. Treat these as an input to help identify apps you might be using, not a definitive source of truth.
: Usually whoever owns compliance, with input from security, IT, and finance. App owners are usually whoever pays for the app or whoever set it up, with IT as the fallback.
: IT is the fallback, and IT already owns your productivity apps anyway. If you can't identify anyone at all, that's worth following up on, since an app nobody will claim is often one nobody is using.
: Continuously. Use events that already happen as the trigger: new subscription charges, new hires, offboarding, and access reviews. Schedule a review of the whole list on top of that, since events only tell you about the apps they touch.
: No. A spreadsheet with one row per app is enough for a first inventory, or use your compliance tool if it already has somewhere to record this.
: If you're a small company building your first one, almost certainly not. Neither tool is really aimed at this: SaaS management platforms started in license and cost management and have moved toward checking how your apps are configured, and CASBs were built to keep data out of places it shouldn't go. Both depend on an integration catalog, so the long tail of apps you're trying to find won't be in it, and neither one substitutes for knowing your apps, sorting them by how much they matter, and locking down the critical ones.
: From the app's own admin console or API, as part of a user access review. Your identity provider knows who can authenticate, not necessarily who holds an account or what role they have.
: Pull what’s in your identity provider and password manager, look at subscriptions, ask each team what they use, and add your environments and internal consoles. Mark whatever holds customer data or touches production. That should get you in a good place for your access reviews while you fill in the rest.