Who should be accountable for access decisions in a shared NHS operating model?

Accountability should stay with the organisation that owns the clinical or operational context, even when the technology is shared. Central teams can standardise policy and evidence, but local leaders should own exceptions and clinical need. That split keeps governance aligned to care delivery rather than to infrastructure convenience.

Why This Matters for Security Teams

In a shared NHS operating model, access decisions fail when accountability becomes diffuse. Central platforms can provide the control plane, but they cannot safely decide clinical necessity in every ward, trust, or pathway. That distinction matters because identity risk is usually not created by the platform itself, but by overbroad access, weak exception handling, and poor ownership of revocation. NHI Management Group’s Ultimate Guide to NHIs shows why governance has to follow the operating context, not just the shared technology stack.

This is also where shared-service assumptions break down. A team can standardise policy templates, but it cannot know when a local service line needs temporary escalation for patient safety, surge demand, or continuity of care. The OWASP Non-Human Identity Top 10 highlights how excessive privilege and weak lifecycle control create the conditions for misuse, especially when no single owner can be held to account. In practice, many security teams encounter privilege sprawl only after an audit finding, incident, or care delivery exception has already exposed the gap.

How It Works in Practice

The cleanest model is shared policy with local accountability. Central identity and platform teams should define guardrails, standard evidence requirements, and technical controls such as least privilege, logging, and time-bound elevation. Local NHS leaders should own the decision to approve access in their clinical or operational context, because they understand the risk, urgency, and necessity of the request.

That split works best when access decisions are treated as a governed workflow rather than a one-time role assignment. Current guidance suggests three practical layers:

• Central teams define policy, default access patterns, and mandatory controls.
• Local accountable owners approve exceptions, temporary access, and clinical overrides.
• Security and audit teams verify that approvals, expiry, and revocation are recorded.

For shared NHS environments, this is where NHI governance needs strong operational evidence. The 52 NHI Breaches Analysis reinforces a familiar pattern: shared credentials, stale permissions, and poor ownership create blind spots that are hard to unwind after the fact. That aligns with the OWASP control focus on lifecycle discipline, especially where access is held for platforms, integrations, and service accounts rather than individual users.

In practice, mature teams pair policy with explicit approvers, expiry windows, and documented purpose. That means access should be granted for a named service, a defined clinical pathway, or a bounded operational event, then reviewed and revoked automatically where possible. These controls tend to break down when shared services span multiple trusts but no single organisation is formally assigned decision authority, because exceptions then outlive the context that justified them.

Common Variations and Edge Cases

Tighter accountability often increases administrative overhead, requiring organisations to balance faster care delivery against stronger approval discipline. That tradeoff is real in emergency care, regional shared services, and cross-trust tooling, where a rigid central process can slow access that is clinically justified.

There is no universal standard for this yet, but current guidance suggests the same principle: the owner of the clinical or operational context should own the decision, while central teams retain control over policy and evidence. In urgent pathways, a designated clinical lead may need delegated authority for time-limited exceptions, provided the decision is logged and reviewed.

One common edge case is platform-owned access for integrations, monitoring, or automation. In those cases, accountability should sit with the service owner who can explain why the access exists and when it should be removed, not with the shared infrastructure team that merely hosts it. Another edge case is outsourced or joint-venture delivery, where contractual ownership must be explicit or accountability becomes ambiguous.

The practical rule is simple: shared technology does not equal shared accountability. The more distributed the model, the more important it is to name the local decision-maker, define the exception path, and make revocation part of the operating rhythm.

Related resources from NHI Mgmt Group

• Who is accountable when an autonomous system acts on access decisions?
• Who is accountable when patient access is shared across third-party apps?
• Who is accountable when risk-based access decisions fail audit or compliance testing?
• Who should be accountable for access decisions inside an IT operations model?