Why More Discovered SaaS Apps Can Mean Better Governance

More discovered SaaS applications can mean better governance when the increase comes from improved visibility rather than uncontrolled adoption. Compare discovery scope, evidence quality, ownership and unresolved-risk trends before interpreting the total. Report what changed in collection coverage, distinguish newly observed from newly created accounts, and measure whether important findings reach a verified governance decision.

In brief

• An application-count increase is not automatically a risk increase.

• Newly discovered does not necessarily mean newly adopted.

• A coverage percentage is only meaningful when its denominator and scope are stated.

• Pair discovery growth with decision quality, backlog age and verified remediation.

The inventory grows after security expands discovery to another business unit. Leadership asks why the SaaS environment is getting worse.

It might not be. The program may have exposed applications that already existed outside the original collection scope. The right response is not to hide the increase. It is to explain the difference between a change in the environment and a change in what the organization can observe.

SaaS discovery coverage metrics should help leaders interpret that difference. Otherwise, the dashboard can reward incomplete visibility and make a successful discovery project look like a control failure.

Separate three reasons an inventory can grow

New adoption

An application or account was genuinely introduced during the reporting period. Establish that using an appropriate account-creation or other supporting event. A first-seen date in a discovery tool is not sufficient by itself.

Expanded observation

The collection scope changed: additional mailboxes, tenants, identity sources or departments became visible. Historical relationships may now appear for the first time. Report the scope change alongside the increase rather than label every additional finding “new usage.”

Changed classification

The inventory's representation changed. A previously merged service becomes two products; a vendor introduces an AI feature; an ambiguous domain is resolved to a known application. Counts can move even when no employee adopted a new tool.

These categories are not always mutually exclusive. A newly connected source may contain recently created accounts. When the cause is unresolved, report that uncertainty and keep it out of claims about adoption speed.

What is the denominator of discovery coverage?

A coverage denominator is the population against which the observed result is compared. “We monitor 90 percent of eligible corporate mailboxes” can be meaningful if the eligible population is defined. “We discovered 90 percent of every SaaS application” requires knowledge of the total application population, including the unknown ones.

Do not treat those statements as equivalent. Source coverage describes where you can look. Inventory completeness describes how much of the actual estate you have identified. Improving one can help the other, but it does not establish a universal completeness percentage.

The NIST Cybersecurity Framework 2.0 includes inventories of software and supplier services. It provides a governance foundation; the metrics proposed here are practical reporting recommendations rather than NIST-mandated formulas.

Metric	Defined population	Interpretation limit
Connected-source coverage	Successfully collected eligible mailboxes or tenants divided by the defined eligible population.	Does not prove all applications are detectable through those sources.
Observed inventory growth	Distinct applications found within a stated scope and comparison period.	Can reflect expanded observation or changed deduplication.
Owner acceptance	In-scope applications with an accountable owner who has accepted responsibility.	A populated owner field alone does not prove acceptance.
Review backlog age	Open findings awaiting a defined governance decision.	Depends on which findings enter the queue and their priority.
Verified closure	Remediation tasks whose stated completion test has passed.	A closed ticket without verification should not count as equivalent evidence.

A rising count can coexist with falling uncertainty

Hypothetical reporting example: a company initially observes 80 applications in one business unit. After expanding collection, it observes 120 across two units. The team also identifies owners for previously unresolved applications and verifies removal of several unnecessary permissions.

The total rose, but the organization gained visibility and completed useful governance work. The figures do not establish a lower overall risk level: the newly observed applications could include serious findings. They show why the count needs context.

A better leadership statement would be: “Collection expanded to the second business unit, adding 40 observed applications. Adoption dates are still being reconciled. We reduced the older review backlog and verified several access-removal tasks. Newly identified high-priority findings remain open.”

This statement separates observation, progress and unresolved exposure. It is more decision-useful than a single green arrow beside a shrinking app count.

Keep SaaS, AI, identity and cloud measures related but separate

An application count does not describe the entire risk surface. One application can have several accounts, multiple grants and an AI capability. Adding those together as interchangeable “assets” produces a number that is hard to interpret.

Cloud hierarchies illustrate the problem. Google Cloud's resource hierarchy documentation distinguishes organizations, folders and projects. A report should define which units it counts rather than label every discovered cloud identifier an equivalent subscription.

For AI, distinguish applications with documented AI features from confirmed tenant enablement and observed activity. The NIST AI Risk Management Framework is a voluntary reference for managing AI risk. Use it to inform the governance conversation without claiming that an inventory field proves compliance or identifies every AI interaction.

The Waldo Security platform connects application, AI, identity, OAuth and cloud context. A useful report presents those relationships and their evidence limits instead of forcing every surface into one headline count.

Make comparisons fair enough to guide action

Whenever possible, compare the same collection scope across periods. If scope changed, show a stable-scope view alongside the expanded view. Label restated historical figures clearly so readers know why an earlier total changed.

Document deduplication rules, status definitions, reporting windows and the treatment of closed accounts. An “unknown application” may mean not yet reviewed under your internal policy; it should not automatically mean malicious, newly created or confirmed to be leaking data.

Break down the backlog by priority and age. A falling unknown percentage can be misleading if the denominator expanded faster than the team resolved important findings. Pair the percentage with the absolute count and describe what a completed review requires.

Five questions for the next governance review

1. What collection sources, departments or tenants changed this period?

2. Which findings are newly observed, and which have evidence of new adoption?

3. What share of the defined inventory has accepted ownership and a current decision?

4. Which important unresolved findings are overdue, and who owns the next step?

5. Which remediation outcomes were verified rather than only marked complete?

These questions keep the conversation focused on decisions. They also expose a program that discovers more information than it can review. In that situation, the answer may be better prioritization, more reviewer capacity or clearer business ownership, not less discovery.

Key takeaways

• Explain why the observed inventory changed before describing risk movement.

• Define denominators and avoid unsupported completeness claims.

• Measure ownership, timely decisions and verified closure alongside counts.

• Use consistent entity and status definitions across reporting periods.

Frequently asked questions

Can an organization report that it found 100 percent of SaaS?

Only if it can substantiate the complete population within a clearly bounded scope. Avoid applying a verified percentage for known sources to an unknown total application estate.

Is a lower unknown-app percentage always improvement?

No. It can fall because the denominator grew. Check the number and priority of unresolved findings, the decision criteria and the reporting scope.

How should first-seen dates be described?

Describe them as first observed by the defined discovery process. Call an account newly created only when a supporting creation event establishes that conclusion.

Should security aim to reduce the application count?

Application retirement may be appropriate, but the primary goal is defensible governance. A smaller count does not demonstrate safer access, better ownership or complete discovery.

How often should coverage metrics be reviewed?

Choose a cadence based on change rate and decision needs. Revisit the metrics after source changes, acquisitions or major classification updates rather than rely only on a fixed annual review.

Can discovery growth prove that Shadow AI is increasing?

Not by itself. Separate improved identification of AI features from new adoption or tenant enablement, and state which conclusion the available evidence supports.

Use discovery to improve the governance conversation

The 2026 SaaS, Cloud & AI Discovery Report explores the relationships behind the governance gap. Use it to frame questions about your own environment, then define scope and evidence before interpreting your organization's trends.

Sources and further reading

• NIST: The NIST Cybersecurity Framework (CSF) 2.0. February 26, 2024.

• Google Cloud: About resource hierarchy. Rolling documentation; accessed October 2, 2026.

• NIST: AI Risk Management Framework. AI RMF 1.0 released January 26, 2023; page accessed October 2, 2026.