Accountability sits with the organisation that owns the lifecycle process, not with the badge, system, or individual workflow that failed. Hospitals should define clear ownership across HR, facilities, security, and IT so revocation cannot stall between teams. Governance frameworks such as NIST Cybersecurity Framework 2.0 help formalise that accountability across protect and detect functions.
Why This Matters for Security Teams
When access remains active after a role change or termination, the failure is usually not technical first. It is an accountability failure across HR, IT, facilities, and security, where each team assumes another team owns revocation. In hospitals, that gap can leave former staff, contractors, or vendors with credentials that still reach clinical systems, badges, and supporting tools long after access should have ended. That is precisely the kind of lifecycle weakness highlighted in the Ultimate Guide to NHIs, where NHI Management Group notes that only 20% of organisations have formal offboarding and revocation processes. The same lifecycle logic applies to human identities when access governance is fragmented. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that account management and access revocation are control obligations, not optional clean-up tasks. In practice, many security teams encounter the breach after a departed worker’s access is still live, rather than through intentional offboarding testing.
How It Works in Practice
Accountability should be assigned to the organisation that owns the access lifecycle, with named control owners for onboarding, transfer, and termination. In hospitals, that usually means HR triggers the event, but IT, IAM, facilities, and application owners must execute and verify revocation across their own systems. The point is not who noticed the change first. The point is who is accountable if access remains active.
Practically, teams should define this in policy, then enforce it through workflow and evidence. The most reliable pattern is a termination or role-change workflow that automatically:
- removes directory and application entitlements
- disables badges, VPN, and remote access
- revokes active sessions and tokens
- confirms completion with logs or ticket closure
- escalates exceptions when a system cannot be updated immediately
This aligns with the lifecycle emphasis in the NHI Lifecycle Management Guide, which treats provisioning and revocation as continuous control points rather than one-time administrative events. It also maps cleanly to the intent of the OWASP Non-Human Identity Top 10, because stale access is an identity risk even when the identity is not human. Hospitals should test termination paths the same way they test downtime procedures: by verifying that all high-risk systems actually close access, not just that a request was submitted. These controls tend to break down when legacy clinical platforms cannot consume central identity signals because manual exceptions then become the default instead of the exception.
Common Variations and Edge Cases
Tighter revocation often increases operational overhead, requiring hospitals to balance speed of offboarding against uptime for clinical and administrative systems. That tradeoff becomes visible when a terminated clinician still needs limited chart access for legal or continuity reasons, or when facilities contractors need time-bounded badge access after a role change. Current guidance suggests those cases should be handled through documented exceptions, not informal delay.
There is no universal standard for this yet, but best practice is evolving toward short-lived exception windows, explicit approvers, and automatic expiry. Hospitals should avoid treating “temporary” access as a verbal agreement, because that creates invisible risk and weak evidence. One useful operational marker is whether the exception is time-boxed and reviewed, or whether it simply persists until someone remembers to remove it.
Where organisations struggle most is not the policy language, but the handoff between HR, identity teams, and application owners. The same lesson appears across NHI governance: if ownership is unclear, revocation drifts. NHI Management Group’s Top 10 NHI Issues shows that lifecycle gaps and excessive privilege are recurring failure modes, and the lesson translates directly to hospital access governance. In practice, ambiguity in ownership is what lets “active but should be closed” access survive routine audits.
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 NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Addresses access management and revocation accountability during role changes and terminations. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Lifecycle revocation failures mirror stale identity and secret issues in NHI programs. |
| NIST SP 800-63 | Digital identity proofing and lifecycle governance inform accountable account disabling. | |
| NIST Zero Trust (SP 800-207) | SC.L2-3 | Zero trust assumes access must be continuously validated and promptly withdrawn. |
| NIST AI RMF | GOVERN | Governance assigns ownership and accountability for access decisions and exceptions. |
Assign named owners for access changes and verify every termination removes entitlements promptly.
Related resources from NHI Mgmt Group
- Who is accountable when access is left active after a role change or departure?
- Who is accountable when Office 365 access stays active after role changes?
- Who is accountable when a hospital contractor keeps access after the work ends?
- Who is accountable when privileged access remains in place after a role change or merger?
