top of page
Search

SaaS Discovery Evidence: What a Finding Actually Proves

Writer: Martin Snyder
Martin Snyder
Oct 5
6 min read

SaaS discovery evidence shows an observed relationship between an application and an organization. Its strength depends on the source, event, identity and date. A signup message can support a historical account association; it does not, by itself, prove current access or active use. Keep those conclusions separate, record uncertainty, and use additional evidence before making access or governance decisions.


In brief

  • Separate account association, access permission and observed activity.

  • Keep the original event and its date alongside the interpreted finding.

  • Use discovery to start an investigation, then verify the claim needed for the decision.

  • Treat absent evidence as a visibility limitation, not proof that an account does not exist.



A security analyst finds a signup confirmation for a design tool in an employee mailbox. The procurement list contains no matching vendor. That is useful information: an application may sit outside the known inventory. But it leaves several questions open. Was the message forwarded? Was signup completed? Does the account still exist? Can the employee still access it?

A reliable inventory does not compress those questions into one label called “usage.” It preserves enough context to answer them separately. That distinction matters when the next step is an access review, an AI vendor assessment or employee offboarding.

What does SaaS discovery evidence actually establish?

SaaS discovery evidence is information used to identify or assess an application's relationship with an organization. It can include account notifications, identity-provider records, application permissions, administrator exports and other authorized sources. Each source observes a different part of that relationship.

The NIST Cybersecurity Framework 2.0 includes maintaining inventories of software, systems and services provided by suppliers. The evidence model below is a practical recommendation for implementing a trustworthy inventory; it is not a prescribed NIST scoring scheme.

Signal

Reasonable interpretation

What remains unverified

Account-created confirmation

The message records an account-creation event for the named identity.

Current account state, successful access and subsequent activity.

Password-reset notification

A reset-related event occurred or was requested.

Who initiated it, whether it succeeded and whether access remains.

OAuth permission record

A recorded authorization relationship exists within the queried system.

Whether the application recently exercised that permission.

Successful sign-in record

The recorded identity authenticated through that observed path at that time.

Activity outside the source's scope and continued business need.

Current administrator account export

The account appears in the queried application's current record.

Activity, effective permissions and legitimate ownership unless separately checked.

Even strong evidence has boundaries. An administrator export may show an account that is suspended. A sign-in event may show authentication without proving a document was viewed. A mailbox signal may refer to a tenant different from the organization's centrally managed instance.

Use four questions before labeling a finding

1. What was observed?

Write down the actual event before interpreting it. “Account invitation received” is more precise than “employee uses application.” Preserve the source reference, collection time and event time. Those timestamps answer different questions: when the event happened and when the discovery process learned about it.

2. Which identity and application does it concern?

Distinguish the message recipient from the account identifier named in the message. Shared mailboxes, forwarding rules and reused addresses can make attribution ambiguous. Record the vendor, product and tenant separately where supporting information is available.

3. What conclusion is needed?

An inventory review may only require evidence of an organizational association. An offboarding task requires a current access determination. An incident investigation may require proof of a particular action. Choose the verification method based on that question instead of asking one discovery signal to answer everything.

4. What would change the conclusion?

Define a next check. It might be an authorized administrator export, confirmation from the account owner or a review of current permissions. Give unresolved findings an owner and a due date. Avoid silently promoting “possible association” to “confirmed active use” as the record moves between tools.

Permissions are evidence of access potential, not activity

Microsoft's permissions and consent documentation distinguishes delegated access on behalf of a user from app-only access through an application's own identity. This matters because a user association does not describe every access path an integration may have.

Similarly, the Google Admin SDK token resource exposes information about user-issued application access tokens, including scopes. A permission record can guide a review of what an application is authorized to access. It should not be presented as a log of the data it actually accessed.

In practice, keep authorization and activity as different fields. That prevents a stale grant from disappearing simply because no recent activity was found, and prevents a grant from being reported as confirmed data exfiltration without evidence.

A practical evidence record

Use a small record that an analyst can inspect without reopening the entire collection process:

  • Observed event: the account, permission or activity event actually recorded.

  • Source and scope: mailbox, tenant, directory or application queried, plus known limitations.

  • Identity: account identifier and attribution status.

  • Application context: product, vendor and known tenant or workspace.

  • Times: event time, collection time and latest verification time.

  • Conclusion: association, recorded permission, observed activity or verified account state.

  • Uncertainty: the specific unanswered question.

  • Next action: reviewer, verification task and deadline.

NIST's SP 800-53 control catalog provides inventory, account-management and audit-control references. The fields above are an operational design choice, not a claim that collecting them alone satisfies those controls or an audit.

Example: one finding, three different decisions

Hypothetical example: an employee mailbox contains a six-month-old account-created message for a writing application. The employee has since moved from marketing to finance.

For discovery, record the historical association and check whether the application belongs in the inventory. For an access review, verify the current account and its permissions against the new role. For AI governance, review the application's available AI features and vendor evidence, then confirm whether those features are enabled for the relevant account.

The same original signal starts all three investigations. It does not complete any of them. Keeping that distinction visible makes the finding useful rather than misleading.

How continuous discovery improves the evidence process

Continuous discovery gives teams additional opportunities to identify new relationships and revisit unresolved ones. It does not turn every observation into proof of active use. Preserve historical findings, incorporate later evidence and make changes to conclusions traceable.

Waldo Security's SaaS discovery helps identify applications and associated identities beyond traditional inventories. The Waldo platform adds context across SaaS, AI, OAuth and cloud relationships. Teams can use that context to choose the next governance check while keeping discovery evidence distinct from verified runtime behavior.

Key takeaways

  • A discovery finding should state what happened, what it supports and what remains unknown.

  • Account association, authorization and activity answer different questions.

  • Verify current access before treating historical signals as an offboarding result.

  • AI capability and actual tenant configuration require separate review.

Frequently asked questions

Does a password-reset email prove an employee still has access?

No. It indicates a reset-related event, but may not establish who requested it, whether it succeeded or the account's current state. Verify access through an authorized source.

Should an old signup finding be removed from the inventory?

Not automatically. Preserve its historical context and review the current relationship. Mark the account closed, inactive or unresolved only when supporting evidence justifies that status.

Is a shared mailbox a SaaS account owner?

Not necessarily. The mailbox may receive notifications for a team account. Identify the login identity, delegates and accountable business owner separately.

Does no recent sign-in mean an application is safe to ignore?

No. The source may not cover local authentication, app-only integrations or every account. Review remaining authorization and account evidence before deciding no action is needed.

Can discovery evidence prove that AI received sensitive data?

Application discovery and vendor documentation can identify possible exposure paths. A claim about a specific transmission requires evidence of that event and its scope.

What should an unresolved finding say?

State the supported association, the missing verification, the responsible reviewer and the next check. “Current access unknown” is more useful than an unsupported active or inactive label.

Make findings useful for the next decision

Explore SaaS discovery with Waldo Security to identify application and identity relationships your current inventory may miss. Use each finding as a starting point for a documented, evidence-based review.

Sources and further reading

Comments

bottom of page