IAM modernisation should be owned jointly by the identity team and the business stakeholders that depend on access outcomes. In a complex university and hospital environment, IT needs clear governance, but departments must also support adoption, training, and prioritised deliverables. Without shared ownership, implementation drifts, timelines slip, and controls remain fragmented.
How should ownership be structured when IAM modernisation cuts across hospitals, universities, and shared services?
Ownership works best as a joint model, not a single-team handoff. The identity function should lead the technical direction, but the departments that rely on access outcomes must own requirements, adoption, and local change impacts. In a hospital and university setting, that usually means a central governance layer with federated execution across clinical, academic, research, and administrative units.
Why shared ownership is the practical answer in a federated institution
IAM modernisation fails when it is treated as an infrastructure refresh instead of an operating-model change. Access decisions affect patient care, teaching, research, onboarding, offboarding, and third-party collaboration, so the people closest to those workflows need a formal role in prioritisation and sign-off. Central IT can standardise controls, but it cannot substitute for departmental knowledge of exceptions, timing, and business criticality.
That is why shared ownership should be explicit. The identity team should own architecture, standards, integrations, and policy enforcement, while business stakeholders own use-case validation, service readiness, and local adoption. Where a university and hospital share platforms, a identity security programme helps define the operating model, while an IAM and Identity Provider Buyer’s Guide is useful when the modernisation includes platform selection or migration decisions.
Modernisation also needs lifecycle discipline. If accounts, access paths, and privilege decisions are not governed consistently from joiner to mover to leaver, the programme will create new technical debt faster than it removes old fragmentation. A lifecycle management guide is especially relevant when shared services include service accounts, automation, or other machine-access paths that must be inventoried and governed alongside human access.
What ownership should cover beyond “who approves the project”
Ownership needs to be separated into decision rights, delivery responsibility, and local accountability. The identity team should own identity architecture, policy design, integration patterns, and technical controls. Departments should own business rules, adoption readiness, exception justification, and the operational impacts of each migration wave. Executive sponsors should own conflict resolution when clinical, academic, or research priorities compete.
A useful rule is that the team responsible for the risk should also be responsible for the decision inputs. If a department depends on a particular access workflow, that department must help define what “good” looks like and what a tolerable exception is. Central governance can then translate those needs into a standardised model rather than negotiating one-off builds forever.
For institutions that are consolidating platforms, the main ownership challenge is often not technology selection but control adoption. A control becomes durable only when the local owners can explain it, use it, and support it during peak operational periods. That is why workload identity guidance and cloud privilege management guidance matter whenever the modernisation reaches shared platforms, research systems, or cloud-hosted services.
How to prevent fragmentation during rollout and steady state
The main failure mode is unclear ownership of the exceptions. Teams agree on a target state, but no one owns the edge cases, legacy integrations, or temporary compensating controls. That produces delayed cutovers, inconsistent enforcement, and a long tail of access paths that remain outside the new governance model.
Practically, the programme should define one accountable governance forum, one technical authority, and named business owners for each major population or service cluster. The governance forum should resolve cross-domain conflicts, the technical authority should set patterns and guardrails, and the business owners should confirm whether the rollout matches the operational reality of their area. That structure is especially important in environments where one identity platform serves both high-availability clinical workflows and decentralized academic use cases.
If the modernisation includes broader access rationalisation, the same ownership model should govern privileged access and account hygiene. The organisation should be able to trace who requested the change, who approved the business need, who implemented it, and who will review it after go-live. Without that chain of accountability, IAM modernisation tends to become a series of disconnected technical projects rather than a durable operating model.
Risk and Threat Considerations
When ownership is split informally, the biggest risk is not just delay, it is control drift. Different departments may keep using local workarounds, retain excess access, or delay retirement of legacy accounts, which leaves the institution with fragmented enforcement and unclear accountability across critical systems.
Failure mechanism: Central teams can standardise architecture, but if departments are not accountable for adoption and exception closure, legacy access paths persist and modern controls never fully replace them.
Impact: The result is slower delivery, inconsistent user experience, weaker auditability, and a larger attack surface if stale or overprivileged access remains in place.
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, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Shared ownership must cover account lifecycle and access governance across departments. |
| Recommendation — Define accountable owners for account lifecycle decisions and review access regularly. | ||
| NIST CSF 2.0 | GV.RR-03 — Roles, Responsibilities, and Authorities | This question is about who owns IAM modernisation across multiple departments. |
| Recommendation — Assign clear decision rights and authorities across central IT and business stakeholders. | ||
| NIST SP 800-53 Rev 5 | PM-23 — Information and Communications Technology (ICT) Supply Chain Risk Management Plan | Modernisation across shared services needs formal governance and coordination across providers and departments. |
| Recommendation — Document ownership, coordination, and escalation paths for shared service changes. | ||
| ISO/IEC 27001:2022 | A.5.2 — Information security roles and responsibilities | Cross-enterprise IAM ownership requires explicit role assignment and accountability. |
| Recommendation — Define and communicate who owns policy, delivery, and operational exceptions. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | IAM modernisation in cloud-hybrid environments depends on governed roles and access ownership. |
| Recommendation — Centralise IAM governance while preserving business ownership of access needs. | ||
Practitioner Guidance
What to prioritise: Establish a named accountable owner for architecture, a named accountable owner for business adoption, and a single forum for exception decisions before the first migration wave starts. If those roles are ambiguous, the programme will default to the loudest department rather than the highest-risk workflow.
What to verify: Check that each affected department can state its required access outcomes, escalation path, and go-live dependencies in writing. If a department cannot explain how it will adopt the new model, it is not ready to be migrated.
Practitioner takeaway: IAM modernisation succeeds when ownership matches the way access is actually consumed, centralised for standards and control, but federated for business truth and adoption.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
