Who should be accountable for access governance in a cross-functional programme?

Why This Matters for Security Teams

access governance fails fastest when accountability is vague. In a cross-functional programme, the work crosses employee lifecycle events, application entitlement design, policy definition, and workflow execution. If every team assumes another team owns the decision, approvals stall, revocations lag, and exceptions become permanent. That is exactly how standing access, orphaned accounts, and audit gaps persist.

The issue is not just process ownership. It is control ownership. Human identity governance and Non-Human Identity governance both show the same pattern: lifecycle management only works when each function owns the part of the process it can actually control. NHIMG’s guidance on the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs makes this clear for machine identities, and the lesson transfers directly to cross-functional access governance for people and systems.

Current guidance from NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 points toward shared accountability with explicit control boundaries, not centralised ambiguity. In practice, many security teams encounter access drift only after a joiner-mover-leaver failure, rather than through intentional governance design.

How It Works in Practice

Effective access governance assigns accountability by lifecycle stage, then binds that accountability to a measurable control. HR owns employment-state signals such as hire, transfer, leave, and termination. App owners own the entitlements and the business justification for each access bundle. Security defines policy, thresholds, and review standards. IT or IAM operations execute the provisioning, deprovisioning, and workflow orchestration.

That division matters because the teams hold different sources of truth. HR sees employment status first. App owners know which access is actually required to do the job. Security understands segregation-of-duties, risk thresholds, and exception handling. Operations can implement automated workflow, but should not be forced to decide entitlement legitimacy without business context. NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis both show how weak lifecycle controls quickly become an exposure problem when ownership is unclear.

A practical operating model usually includes:

• HR triggers create authoritative start, change, and end events.
• App owners approve role templates, exceptions, and access recertification.
• Security sets least-privilege policy, review cadence, and escalation rules.
• IAM or IT automates provisioning and revocation with audit evidence.
• Business leaders resolve disputes when access is needed but not standard.

One NHIMG research point is especially relevant: only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security by Astrix Security & CSA. That confidence gap is a governance signal, not just a tooling issue. These controls tend to break down when identity data lives in multiple HR, SaaS, and IAM systems because no single team can verify the full lifecycle end to end.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance clear ownership against speed and flexibility. That tradeoff becomes visible in matrixed businesses, mergers, and regulated environments where one employee may span multiple business units or control frameworks.

Best practice is evolving on how much authority should sit with a central IAM team versus distributed business owners. There is no universal standard for this yet. In mature programmes, security usually owns policy and exception criteria, but not the right to approve every request. App owners may delegate recurring approvals to role catalogues, while HR remains the authoritative source for employment status. For high-risk access, the bar is higher: some organisations require manager approval plus app-owner approval, with security review for privileged or sensitive entitlements.

Cross-functional ownership also differs for human and non-human identities. For machine accounts, service owners often replace HR as the lifecycle trigger source, and the principle aligns with the lifecycle model described in NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives. The same governance logic applies: the team closest to the business event should own the trigger, while security owns policy and assurance.

When access decisions are fed by weak data quality, inherited entitlements, or unclear role ownership, the model degrades quickly. In those cases, the programme often needs a short remediation phase before distributed accountability can work reliably.

Related resources from NHI Mgmt Group

• Who should own privileged access governance in an identity programme?
• Who is accountable when consolidation does not improve access governance?
• What is the difference between role-based access and API key governance for NHI security?
• Where does cross-environment agent discovery fit in an IAM programme?