Who should own SaaS risk when procurement, IAM, and security overlap?

Why This Matters for Security Teams

SaaS risk becomes a governance failure when procurement, IAM, and security each assume another function owns the handoff. Procurement may approve spend without validating access scope, IAM may provision users and service accounts without business context, and security may monitor logs after the fact without authority to block risky onboarding. NHI Management Group’s research shows how often this is already a maturity gap: only 19.6% of security professionals express strong confidence in their organisation’s ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.

That confidence problem matters because SaaS is now the control plane for business workflows, data sharing, and third-party integrations. The right question is not who “owns” SaaS in the abstract, but who is accountable for approval, identity governance, logging, and offboarding at each stage of the lifecycle. The NIST Cybersecurity Framework 2.0 reinforces that governance, access control, and monitoring must be coordinated rather than separated into silos. In practice, many security teams encounter SaaS sprawl only after renewals, stale integrations, or over-privileged access have already created exposure.

How It Works in Practice

Shared ownership works only when accountability is explicit and operationalized. Procurement should own commercial intake and renewal gates, but not access approval. IAM should own identity lifecycle controls, entitlement review, and provisioning standards, but not vendor selection. Security should own logging requirements, policy enforcement, and exception handling, but not be left as an advisory afterthought. The practical model is a RACI-style split that ties each SaaS app to a named business owner, a technical owner, and a security reviewer.

For SaaS onboarding, the workflow should include identity checks before contract signature, not after deployment. That means verifying SSO compatibility, SCIM support, role model granularity, and deprovisioning capability during procurement. It also means mapping where secrets, API keys, and OAuth grants will be stored and rotated. NHI Management Group’s Top 10 NHI Issues is relevant here because many SaaS risks are really identity lifecycle failures, not pure vendor risk issues.

• Procurement gates vendor approval, contract language, data handling terms, and renewal timing.
• IAM validates SSO, RBAC, SCIM, least-privilege roles, and deprovisioning paths.
• Security defines logging, alerting, exception review, and evidence retention requirements.
• The business owner accepts residual risk and confirms the application’s purpose remains valid.

This model aligns with current guidance from NIST CSF 2.0, which treats governance and risk management as shared but accountable functions, and it mirrors incident patterns seen in real SaaS breaches such as the Salesloft OAuth token breach, where access and authorization boundaries mattered as much as procurement decisions. These controls tend to break down when SaaS is purchased through departmental cards and no integration owner is assigned before the first login is created.

Common Variations and Edge Cases

Tighter ownership usually improves control, but it also increases coordination overhead, so organisations must balance speed against evidence quality. That tradeoff is most visible in high-velocity SaaS buying, shadow IT, and merger environments, where a strict approval chain can slow delivery unless the intake process is lightweight and pre-approved patterns exist.

There is no universal standard for this yet, but current guidance suggests the most reliable structure is a federated model: procurement owns the commercial gate, IAM owns the identity gate, and security owns the control gate. Exceptions are common for low-risk collaboration tools, but they still need a named owner and a documented review interval. For regulated data flows, security should have veto power when logging, access review, or retention cannot be enforced.

Edge cases appear when SaaS is embedded into another platform, when a vendor uses delegated admin models, or when service accounts outlive the contract. In those situations, the ownership question extends beyond the app itself to the identities, tokens, and integrations attached to it. That is why the 2024 Non-Human Identity Security Report is useful for program design: it shows how quickly shared responsibility becomes weak accountability if no one owns the handoff. The practical answer is to assign one accountable owner for the workflow, even when several teams execute parts of it. This guidance breaks down when SaaS procurement is decentralized across many departments and there is no mandatory review checkpoint before renewal.

Related resources from NHI Mgmt Group

• How can teams reduce risk when multiple SaaS tools overlap?
• How can IAM and security teams reduce third-party risk from AI-enabled SaaS tools?
• Who should own cloud identity decisions when security architecture and IAM overlap?
• Who should own third party risk management across security, legal, and procurement?