They should define one governance model for inventory, approval, and remediation, with explicit decision rights for each step. The CIO typically owns operational context, while the CISO owns risk interpretation, but both need a shared process for action. Without that split, access governance becomes inconsistent and slow.
Why This Matters for Security Teams
Shared ownership of access governance is not a paperwork exercise. CIO teams usually understand application dependency, operational urgency, and who needs access to keep services running, while CISO teams are accountable for risk, control design, and exception discipline. When those responsibilities are blurred, approvals become inconsistent, remediation stalls, and nobody can explain why a given identity still has access.
This is especially visible in non-human identity programmes, where access often spans APIs, service accounts, OAuth apps, and automation workflows that sit outside classic joiner-mover-leaver processes. NHIMG research shows that lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, which is a strong signal that governance failures are not just theoretical. The right reference point is a single operating model, aligned to NIST Cybersecurity Framework 2.0 and NHIMG guidance on Regulatory and Audit Perspectives.
In practice, many security teams encounter access sprawl only after an audit finding, a vendor incident, or a failed privilege review has already exposed the gaps.
How It Works in Practice
The cleanest model is to separate operational ownership from risk ownership without splitting the process itself. The CIO or IT operations function typically owns the inventory, request routing, application context, and remediation execution. The CISO function defines policy, minimum control requirements, escalation thresholds, and the conditions under which an exception is acceptable. Both sides should work from the same ticketing flow, evidence standard, and review calendar.
For NHI and agentic environments, current guidance suggests treating access governance as a continuous control loop rather than a periodic review. Inventory should include service accounts, API keys, certificates, OAuth grants, and automation identities, not just human users. Approval should be tied to business purpose, system owner, and data sensitivity. Remediation should be measurable, time-bound, and reversible, with short-lived credentials or just-in-time access preferred where the workload allows it. The OWASP Non-Human Identity Top 10 is useful for framing common failure modes, while NHIMG’s Top 10 NHI Issues helps teams translate those risks into operational priorities.
- CIO owns asset context, service dependency mapping, and execution of access changes.
- CISO owns policy, exception governance, risk acceptance, and evidence standards.
- Both approve the control model, but only one process should exist for requests, reviews, and removals.
- Access decisions should be documented with expiry dates, owners, and review triggers.
These controls tend to break down in hybrid environments with fragmented IAM tools because no single team can see the full access path from request to revocation.
Common Variations and Edge Cases
Tighter access governance often increases operational overhead, so organisations have to balance speed against assurance. That tradeoff matters most when business units want fast onboarding for vendors, engineers, or automation, but security needs defensible approvals and timely revocation.
There is no universal standard for exactly how CIO and CISO decision rights should be divided, but best practice is evolving toward a RACI-style model with explicit escalation paths. In highly regulated environments, the CISO may require mandatory approval for privileged or externally exposed access, while the CIO retains authority for operational exceptions under pre-approved guardrails. In lower-risk cases, the CIO can approve routine access changes if policy checks are automated and the CISO receives exception reporting.
Edge cases include inherited access from mergers, shared admin accounts, outsourced operations, and machine-to-machine relationships where ownership is unclear. NHIMG’s Key Challenges and Risks section is useful for understanding why these cases persist, and the broader Ultimate Guide to NHIs provides lifecycle context for ownership handoffs. The practical test is simple: if a team cannot name the approver, reviewer, and remover for a given identity type, the governance model is not finished.
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 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 | Defines access permissions management across systems and identities. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers weak lifecycle governance for non-human identity credentials. |
| NIST AI RMF | Supports governance, accountability, and risk management for autonomous access decisions. |
Assign clear approval and review duties, then enforce least privilege through a shared access workflow.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
