MSPs should start with complete discovery across the client environment, including both approved and shadow IT applications. The goal is to build a trusted inventory before changing access or renewal decisions. Without that baseline, teams cannot judge risk, eliminate duplication, or spot unused subscriptions. Discovery turns SaaS management from guesswork into a controlled process with evidence behind every action.
Why discovery comes before centralising SaaS control
Centralising control only works when the MSP knows what is actually in use. Discovery should capture sanctioned applications, shadow IT, overlapping tools, and dormant subscriptions so the team can separate real risk from noise. A complete inventory also exposes where access decisions, renewal decisions, and ownership are missing, which is why discovery belongs before policy enforcement or consolidation.
For MSPs, the practical test is whether each application can be tied to a business owner, a tenant, and a reason it exists. If any of those are missing, centralisation will be driven by assumptions rather than evidence. That is where SaaS sprawl persists, because the service may look managed while the actual usage pattern remains fragmented.
Discovery also changes the conversation from product count to control scope. Once the portfolio is visible, teams can distinguish genuine duplication from intentional redundancy, and can see which applications should be governed tightly versus simply monitored until ownership is clarified. That sequencing matters because central control over an incomplete inventory often creates false confidence and missed exposure.
What a defensible SaaS discovery baseline should include
A useful baseline is broader than a list of app names. It should show who uses each SaaS service, whether the app is approved, what data it touches, how it was procured, and whether it is still active. That is the minimum needed to support later decisions on access, renewal, rationalisation, and offboarding.
Discovery should also reconcile multiple sources of truth. Procurement records, SSO logs, browser activity, expense data, and endpoint telemetry often reveal different slices of the same estate. When those sources are compared, MSPs can find apps that were bought but never deployed, apps that are heavily used outside standard buying channels, and apps that have become orphaned after a team or project changed.
The most reliable baseline is one that can support action without constant manual re-checking. That is why many teams map discovery into lifecycle governance concepts, including inventory, ownership, and offboarding. NHIMG’s NHI Lifecycle Management Guide is useful here because it frames discovery as part of a managed lifecycle rather than a one-time audit.
When discovery is mature, the inventory itself becomes decision-ready. Teams can ask which tools are duplicated, which are unused, which are high-risk because they touch sensitive data, and which are still justified because they serve distinct workflows. That supports controlled centralisation instead of blanket consolidation.
How to move from discovery to control without breaking trust
Centralisation should follow the evidence, not precede it. Start by classifying applications into approved, tolerated, and unknown categories, then assign ownership and usage confidence before changing access policies or renewal terms. If you centralise too early, you risk disabling tools that are business-critical but poorly documented, or preserving subscriptions that are no longer needed simply because no one has validated the baseline.
A good implementation sequence is to discover, normalise, validate ownership, identify duplication, and only then decide what to retire, retain, or bring under tighter control. That sequence lets MSPs focus effort on the few services that drive most exposure, rather than spreading attention across every known SaaS login at once.
For practitioners who want a broader identity and governance lens on the same problem, NHIMG’s Top 10 NHI Issues and Lifecycle Processes for Managing NHIs both reinforce the same operational principle: you cannot govern what you have not fully inventoried, classified, and owned.
Risk and Threat Considerations
Discovery gaps create two kinds of exposure: unmanaged SaaS can retain access or data paths that nobody actively reviews, and overcentralisation can remove services before their business role is understood. In both cases, the problem is not just inventory quality, but the false assumption that control has been established when visibility is still partial.
Failure mechanism: Shadow IT, duplicate subscriptions, and orphaned accounts hide in separate procurement, SSO, and usage records, so the MSP centralises around an incomplete view and misses both unused spend and real access risk.
Impact: The client can keep paying for services that are no longer needed, while sensitive applications remain outside effective governance or are disrupted by premature consolidation decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | SaaS discovery depends on knowing what assets and services exist. |
| Recommendation — Maintain a current SaaS asset inventory before consolidating control or renewing licenses. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Discovery is the identity-and-asset baseline needed before governance decisions. |
| Recommendation — Inventory SaaS assets and dependencies before changing access or ownership controls. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | A SaaS baseline is an information-asset inventory problem before central control. |
| Recommendation — Maintain an up-to-date SaaS inventory to support later access and renewal decisions. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Complete discovery is required to identify and manage all SaaS components and subscriptions. |
| Recommendation — Build and reconcile a complete SaaS component inventory before centralizing controls. | ||
| SOC 2 (AICPA) | CC7.2 — Identify and respond to security events | Shadow IT and unknown SaaS usage require monitoring and response over the application estate. |
| Recommendation — Monitor SaaS discovery signals so unknown or dormant services are identified quickly. | ||
Practitioner Guidance
What to prioritise: Build a single reconciled inventory before you change entitlement, renewal, or standardisation decisions. The first pass should prove ownership and active use, not just count applications.
What to verify: For each SaaS app, verify that you have a business owner, a tenant or subscription record, and at least one usage signal that confirms whether it is live, dormant, or shadow IT. If those three items do not align, treat the record as unresolved.
Common mistake: MSPs often start by rationalising licenses or forcing a preferred stack, which can obscure real demand and make the final control model look cleaner than it is. Discovery has to expose the mess first, otherwise centralisation optimises the wrong dataset.
Practitioner takeaway: Treat discovery as the control foundation, not a reporting exercise. The quality of the inventory determines whether centralisation becomes governed change or just another layer of assumption.
Related resources from NHI Mgmt Group
- How should security teams handle shared SaaS accounts before they become a control gap?
- How should financial institutions implement data discovery before they can govern sensitive information at scale?
- What do teams get wrong when they try to scale access control across multiple SaaS applications?
- What breaks when teams try to centralize telemetry before they can investigate?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
