Ownership should sit with the team that can coordinate operational execution and governance together, usually IT or identity operations working closely with security and business stakeholders. Multi unit environments need clear responsibility for onboarding, offboarding, access review, and device tracking, otherwise gaps appear between procurement, provisioning, and revocation. The key is assigning one accountable function while keeping cross functional input for policy and exceptions.
How ownership should work when SaaS visibility and device lifecycle span multiple business units
Ownership should follow the function that can actually enforce the process end to end, not the org chart that happens to pay for the tools. In practice, that means one accountable team for policy, workflow, and exception handling, with business units contributing local context and approvals. This is as much a governance design problem as it is an operating model problem.
When that accountability is fragmented, SaaS discovery, onboarding, offboarding, and device tracking drift apart. A business unit may approve a tool, IT may provision access, and security may assume someone else is monitoring revocation, which is how stale access and unmanaged devices persist. A clear owner reduces ambiguity around who closes those gaps.
For organisations with multiple business units, the ownership model should distinguish between identity and access governance, operational execution, and business approval. The best pattern is usually a central control owner, often IT, identity operations, or a platform team, with delegated business stewards for local exceptions and risk acceptance.
Why a single accountable owner matters more than shared responsibility
Shared responsibility sounds balanced, but it often fails when no team owns the final action. saas visibility depends on consistent discovery, inventory, and entitlement review, while device lifecycle control depends on enrolment, status changes, retirement, and revocation. If those activities sit in different silos, each team can claim partial ownership while the overall control remains incomplete.
A single accountable owner gives the organisation one place to define standards, measure completion, and escalate exceptions. That owner does not need to perform every task, but it must have the authority to coordinate IT, security, procurement, and business stakeholders. Without that authority, the control becomes advisory instead of enforceable.
In larger environments, the right answer is often a federated model rather than full centralisation. The central function sets the rules for SaaS registration, device lifecycle states, and review cadence, while business units supply asset context and approve local exceptions. IAM and IGA Basics is a useful reference point for separating governance from execution in that model.
What the owner must control across the lifecycle
The owner needs to control the moments where risk is created or removed: onboarding, offboarding, access review, and device retirement. For SaaS, that includes knowing which applications exist, who approved them, who has access, and whether access is still needed. For devices, it includes knowing which assets are enrolled, assigned, active, lost, retired, or overdue for removal from management.
That lifecycle view matters because failures usually appear at handoff points. Procurement may approve the spend, provisioning may create the account, and offboarding may remove the person from HR, yet the SaaS entitlement or device record remains untouched. The control owner must therefore own the reconciliation process, not just the policy document.
Where non-human access or shared tooling exists, the same lifecycle discipline should extend to credentials and administrative access paths. Joiner-Mover-Leaver (JML) Guide and NHI Lifecycle Management Guide both reinforce the practical point: ownership has to include revocation, not just provisioning, if the organisation wants lifecycle control rather than lifecycle paperwork.
Risk and Threat Considerations
When ownership is split across business units, the most common failure is not a single control break, but a chain of small misses: a SaaS app is approved in one place, tracked in another, and never formally revoked when the user or device changes state. That creates lingering access, incomplete inventories, and weak accountability for exceptions.
Failure mechanism: fragmented accountability leaves gaps between procurement, provisioning, review, and deprovisioning, so stale SaaS accounts and unmanaged devices survive normal change processes.
Impact: the organisation loses visibility over who can access what, which increases the chance of unauthorised access, compliance gaps, and delayed response when an account, device, or application is no longer legitimate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | SaaS visibility and lifecycle ownership depend on cloud IAM governance across business units. |
| Recommendation — Define a single IAM owner for SaaS entitlement review, joiner-mover-leaver flow, and exception handling. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | SaaS onboarding, offboarding, and review are account lifecycle controls that need clear ownership. |
| Recommendation — Assign account lifecycle ownership and require timely provisioning, review, and removal. | ||
| CIS Controls v8 | CIS-5 — Account Management | Device and SaaS lifecycle control depends on account management and ownership accountability. |
| Recommendation — Centralise account ownership and verify removals during offboarding and asset retirement. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Ownership of SaaS and device controls is an access-control governance issue in the ISMS. |
| A.5.9 — Inventory of information and other associated assets | SaaS visibility and device lifecycle both depend on a reliable inventory owned by someone accountable. | |
| Recommendation — Set access-control ownership and define approval, review, and revocation responsibilities. Maintain an owned inventory of SaaS services and managed devices, with regular reconciliation. | ||
Practitioner Guidance
What to prioritise: assign one accountable owner for the control plane, then document which teams execute discovery, provisioning, review, and offboarding. The owner should be able to prove that every SaaS application and managed device has a current lifecycle state and a named exception path.
What to verify: check whether the organisation can answer three questions without manual detective work: who approved the SaaS app, who owns the device record, and who is responsible for revocation when the user or asset changes status. If any of those answers depend on informal knowledge, the ownership model is not working.
Practitioner takeaway: multi business unit environments need one accountable function with cross functional inputs, because lifecycle controls only work when someone owns the handoff points where visibility and revocation usually fail.
Related resources from NHI Mgmt Group
- How should organisations govern SaaS sprawl across business units?
- Who should own SaaS app lifecycle decisions when business units self-procure tools?
- What breaks when organisations manage identity separately across multiple business units and platforms?
- How should organisations improve identity visibility when IAM environments are fragmented across business units and cloud systems?
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
