Split governance creates blind spots, inconsistent review coverage, and access that outlives the business need behind it. In banking, that means dormant accounts, excessive entitlements, and vendor access can persist long enough to become audit findings, operational incidents, or escalation paths. A single lifecycle and policy model is needed to keep access both controlled and explainable.
How Split Identity Governance Breaks in Banking
When employee, vendor, and privileged access are governed in separate silos, the bank loses a single view of who can do what, why they still need it, and when it should be removed. That separation turns access review into a coordination problem instead of a control, which is how dormant entitlements, unmanaged exceptions, and inherited privilege persist.
The practical failure is not just duplication. It is that each group is reviewed against a different process, different owner, and different timeline, so the bank cannot reliably prove that access remained appropriate across the full lifecycle.
Seen through that lens, the core issue is identity governance fragmentation: the control surface becomes wider than the operating model that is meant to govern it.
Why Employees, Vendors, and Privileged Accounts Must Share One Policy Model
Employee access, third-party access, and privileged access are different risk profiles, but they still need consistent rules for ownership, approval, recertification, and removal. If each population uses its own model, the organisation ends up with conflicting exceptions, inconsistent evidence for auditors, and gaps where one team assumes another team owns the cleanup.
That is especially important in banking because access often crosses system boundaries. A vendor may hold application support access, an employee may inherit elevated rights through a role change, and a privileged account may remain active after the original task is complete. A shared policy model makes those paths visible enough to govern, rather than relying on local memory or ticket history.
For teams building that model, NHIMG’s Financial Services Identity Security Guide is useful because it frames bank identity obligations across privileged access and third parties, and the Service Account Security Guide extends the same governance logic to non-human and shared operational identities.
What Breaks First: Review Coverage, Traceability, and Removal
Split governance usually fails in three predictable ways. First, review coverage becomes inconsistent, because each group is recertified on a different schedule or by a different owner. Second, traceability weakens, because no one can easily reconstruct why a vendor entitlement or privileged role still exists. Third, removal lags behind business change, so access survives role changes, contract endings, or project completion.
Once that happens, the organisation starts depending on reactive cleanup rather than lifecycle discipline. In banking, that is how excessive entitlements quietly accumulate and why audit evidence often shows access that is technically “owned” by multiple teams but effectively owned by none.
NHIMG’s NHI Lifecycle Management Guide is relevant here because it connects provisioning, rotation, offboarding, and visibility into one lifecycle view, while the Identity Security Posture Management Guide helps teams measure whether dormant accounts, standing admins, and drift are actually being surfaced.
Risk and Threat Considerations
Split identity governance in banking creates a control gap that attackers and auditors both exploit. If a vendor account, privileged role, or employee entitlement is not reviewed through the same lifecycle logic, it can persist after business need ends and remain usable long enough to become an access path, an escalation path, or an audit failure.
Failure mechanism: ownership fragmentation delays revocation, hides excessive privilege behind separate processes, and leaves dormant or inherited access outside a consistent review and offboarding cycle.
Impact: the bank can accumulate stale access, increase the blast radius of a compromise, and lose the ability to prove that access decisions were current, justified, and controlled.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Split lifecycle ownership directly affects account provisioning, review, and removal across user classes. |
| AC-6 — Least Privilege | Excessive entitlements and inherited privilege are the main failure modes in fragmented governance. | |
| IA-5 — Authenticator Management | Banking access often persists through credentials and secrets that must be rotated and retired with lifecycle events. | |
| Recommendation — Centralise account lifecycle ownership and enforce timely review and deprovisioning. Limit each identity to the minimum access needed and remove standing excess. Track, rotate, and retire authenticators when access purpose or ownership changes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | One access policy model is needed to keep employee, vendor, and privileged access governable. |
| A.5.18 — Access rights | The issue is whether access rights are reviewed, changed, and removed consistently across populations. | |
| Recommendation — Define a single access-control policy across all identity populations. Review and revoke access rights on a defined lifecycle cadence. | ||
Practitioner Guidance
What to prioritise: Put employee, vendor, and privileged access into one recertification and offboarding policy even if the operating teams stay separate. The policy should answer who owns the decision, when access expires, and what evidence proves the access is still needed.
What to verify: Check whether every access path has a single accountable owner and a removal trigger tied to employment change, contract end, or privilege expiry. If the answer depends on a manual chase across teams, the control is already weaker than it appears.
Decision rule: If an entitlement can survive without a current business purpose being revalidated, treat it as a governance defect, not just an administrative delay. That is the point where review failure becomes operational exposure.
Practitioner takeaway: Banking identity management breaks most often when lifecycle ownership is split more than the access itself. The control objective is to make every grant, review, and removal decision explainable in one model, even if the identities serve different functions.