SaaS security should be shared, but leadership owns the policy and accountability. Business teams need to surface their app choices, security teams need to monitor and enforce controls, and IT needs visibility into identities, authentication, and consolidation opportunities. If ownership is unclear, employees will keep making independent decisions and the organisation will continue to accumulate hidden risk.
How SaaS ownership should work when buying and security happen out of order
In practice, SaaS security cannot sit in one team if procurement is decentralised. The business function chooses the tool because it owns the workflow, but security and IT must still define the control baseline, the required approval path, and the visibility needed to see who connected, with what account, and through which authentication method. That is the only way to keep control without blocking legitimate business use.
A useful operating model is to treat the business as the demand owner, security as the policy and control owner, and IT as the technical visibility and integration owner. That division reflects how NHIMG’s Ultimate Guide to NHIs frames visibility, lifecycle, and credential governance around the systems that actually touch SaaS, including identities, tokens, and secrets. It also keeps ownership with the team best placed to understand the process risk, while still forcing standard controls around onboarding, authentication, and access review.
Where organisations fail is not usually at the point of tool purchase, but after purchase, when no one records the application, the tenant, the admin accounts, or the API connections. That gap is where shadow SaaS becomes shadow access, because a business team can connect a new platform using a personal account, a shared mailbox, or a long-lived token without any durable record in IT or security. Once that happens, remediation becomes discovery work rather than governance work.
What each team should own so SaaS does not become shadow IT
Business teams should own use-case justification, app selection, and timely disclosure of new tools. Security should own policy, risk acceptance criteria, control enforcement, and monitoring for high-risk patterns such as unsanctioned integrations, weak authentication, or excessive privilege. IT should own inventory, identity integration, and the operational controls that make SaaS visible in directories, logs, and access reviews. None of those functions can be optional if the organisation wants a reliable control plane.
For identity-heavy SaaS environments, the most important question is not who bought the tool, but whether the organisation can see every actor and every secret that grants access. Service accounts, API keys, OAuth grants, and admin sessions often outlive the original business need, especially when the tool is adopted outside normal procurement. That is why SaaS ownership should include a clear rule for app registration, delegated administration, and periodic review of the accounts and tokens created to run the service.
Business-led buying also means consolidation opportunities usually appear late, after several teams have already chosen overlapping tools. IT needs authority to identify duplicate platforms, redundant integrations, and unmanaged identity paths, then feed those findings back into standardisation. Without that feedback loop, the organisation pays for the same control problem multiple times and inherits multiple audit trails that do not line up.
Risk and Threat Considerations
Decentralised SaaS buying creates hidden exposure because the organisation loses track of which applications can authenticate, what data they can reach, and whether the related accounts or tokens are still in use. The main threat is not just unauthorised purchase, but ungoverned access paths that persist after the original business owner forgets them.
Failure mechanism: A team connects SaaS through a personal login, unmanaged admin account, or long-lived token, then the relationship is never formally offboarded or reviewed. That leaves a durable access path outside normal inventory, monitoring, and revocation processes.
Impact: Attackers, former employees, or even well-meaning staff can keep using stale access to reach data, move laterally through connected systems, or create duplicate tooling that weakens standard controls. Over time, the organisation accumulates invisible privilege and fragmented accountability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | SaaS apps often rely on tokens and API keys that need governance. |
| NHI-03 — Privilege and Access Governance | Decentralised SaaS buying often creates excessive admin and integration privilege. | |
| NHI-07 — Lifecycle and Offboarding | Unregistered SaaS accounts and tokens persist when ownership is unclear. | |
| Recommendation — Inventory SaaS secrets, rotate them, and remove long-lived credentials from unmanaged storage. Enforce least privilege for SaaS admins, service accounts, and connected integrations. Require joiner-mover-leaver style offboarding for SaaS accounts, tokens, and connected apps. | ||
| CIS Controls v8 | 5 — Account Management | Shared SaaS ownership depends on knowing which accounts and admins exist. |
| 6 — Access Control Management | The answer depends on enforcing approved access paths and revocation. | |
| 15 — Service Provider Management | Business-led SaaS buying creates third-party dependency and oversight risk. | |
| Recommendation — Maintain an authoritative inventory of SaaS accounts, administrators, and service identities. Restrict SaaS access to approved identities and revoke unused or excessive access promptly. Assess and track SaaS providers, contracts, and security responsibilities before enabling use. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Ownership of SaaS must align to business process and accountability. |
| ID.AM-07 — Platform Inventory | The issue is largely invisible SaaS and identity sprawl. | |
| PR.AA-01 — Identity Management, Authentication, and Access Control | SaaS governance hinges on identities, authentication, and access enforcement. | |
| Recommendation — Define SaaS ownership and accountability in line with business context and risk appetite. Keep an up-to-date inventory of SaaS applications, tenants, and connected identities. Apply central identity and access controls to every approved SaaS application. | ||
Practitioner Guidance
What to prioritise: Establish a single SaaS intake rule that applies before or immediately after purchase, then require every application to be tied to an owner, an admin path, and an identity review record. If the app cannot be registered, it should not be considered operationally approved.
What to verify: Check whether the organisation can name the business owner, the technical owner, the authentication method, and the offboarding process for each SaaS app. If any one of those is missing, the control model is incomplete even if the app appears harmless.
Common mistake: Treating SaaS as a procurement issue alone. The real failure is governance drift, because tool choice without identity visibility and enforcement creates a permanent blind spot.
Practitioner takeaway: Shared ownership works only when leadership assigns clear accountability and operational visibility, otherwise business convenience simply turns into unmanaged access.
Related resources from NHI Mgmt Group
- How should security teams make NHI best practices usable across the business?
- Why do AD security tools often leave governance gaps when teams buy for detection first?
- How should security teams build a business case for modern IGA in a SaaS-first environment?
- What should organisations do when business teams need SaaS tools but security still has to reduce exposure?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
