Accountability usually sits with IAM, identity governance, and security leaders because they own the control design, review cadence, and escalation paths. If governance depends on tickets and manual audits, the organisation owns the resulting visibility gap. The practical response is to define control ownership, automate high-volume workflows, and measure whether reviews and revocation happen in time.
Why This Matters for Security Teams
When cloud and SaaS permissions change faster than humans can review them, accountability does not disappear, but it does become easier to blur. The control gap is usually not a mystery of policy language. It is a failure of ownership, evidence, and cadence. That is why identity governance and IAM leaders are typically accountable for the design and operation of the control, while security leadership is accountable for whether the organisation can prove access is being reviewed and removed on time.
This is especially important because modern identity risk is dominated by scale and drift. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a strong signal that manual governance is not keeping pace with operational reality. The same pattern appears in SaaS and cloud estates, where access changes can be triggered by HR events, project moves, vendor integrations, or automation, all outside the rhythm of monthly access reviews.
Industry guidance from the NIST Cybersecurity Framework 2.0 still places clear weight on governance, accountability, and continuous risk management, but current guidance suggests that control ownership only works when it is matched with measurable execution. In practice, many security teams encounter toxic access drift only after a SaaS audit, a billing review, or an incident has already exposed the gap, rather than through intentional governance.
How It Works in Practice
Accountability is easiest to define when it is tied to specific control outcomes rather than broad job titles. IAM or identity governance leaders usually own the workflow design, review thresholds, and revocation mechanics. Application owners or business managers often own entitlement validation. Security leadership owns oversight, escalation, and evidence that the control actually works. This division matters because manual identity governance breaks when changes are frequent, distributed, and partially invisible.
A practical model uses event-driven access control rather than waiting for periodic reviews. For example, when a user changes teams, leaves a project, or a SaaS connector is added, the identity platform should trigger entitlement recertification or automatic removal. That approach aligns with the OWASP Non-Human Identity Top 10, which emphasizes the risk of excessive privilege, poor lifecycle control, and weak secrets governance across automated identities. It also fits the lifecycle approach described in NHIMG’s Lifecycle Processes for Managing NHIs section, where issuance, rotation, review, and revocation are treated as one continuous control chain.
- Define a named control owner for each identity domain, including cloud, SaaS, and privileged access.
- Set review cadence based on access volatility, not calendar convenience.
- Automate high-risk revocation paths, especially for admin roles and external collaboration access.
- Require evidence of completion, not just evidence that a ticket was opened.
- Escalate overdue reviews as control failures, not administrative delays.
For auditability, teams should map the process to control evidence such as attestation records, exception approvals, and revocation timestamps, using NIST SP 800-53 Rev 5 Security and Privacy Controls as the baseline for review and accountability expectations. These controls tend to break down when access is granted through shadow SaaS admin paths or direct vendor integrations because the authoritative system of record no longer matches the actual permission state.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, requiring organisations to balance faster revocation against business friction and review fatigue. That tradeoff becomes sharper in SaaS-heavy environments where permissions are inherited from groups, nested roles, or external tenants. In those cases, the question is not only who is accountable, but how accountability is proven when the underlying access model is already fragmented.
There is no universal standard for this yet, but current guidance suggests that exceptions should be explicit and time-bound. For example, emergency access, service desk delegation, and third-party admin access should have separate owners, shorter review cycles, and automatic expiry. Manual attestations are still acceptable for low-risk entitlements, but they are a weak fit for privileged cloud roles or high-churn SaaS groups. NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis both reinforce the broader lesson that visibility gaps and missed revocation are often the real failure, not policy absence.
Where accountability gets messy is in federated environments. A SaaS owner may approve access, a cloud platform team may provision it, and a security team may discover the drift only after logging data shows the issue. In those cases, best practice is evolving toward shared accountability with a single system owner for each control. That means one team is responsible for operating the mechanism, while another is responsible for challenging exceptions and enforcing timelines. In practice, organisations that do not assign a single owner for revocation and review usually end up discovering the failure only after access has already outlived its business need.
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 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Clarifies who owns governance outcomes and control accountability. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers lifecycle governance and excessive privilege for non-human access. |
| CSA MAESTRO | Addresses shared accountability and governance for autonomous cloud control paths. | |
| NIST AI RMF | GOVERN | Govern function supports accountable oversight when access changes are automated. |
| NIST Zero Trust (SP 800-207) | 4.2 | Zero trust emphasizes continuous verification and least privilege as access changes. |
Establish accountability, escalation, and monitoring for identity governance controls as part of AI risk governance.
Related resources from NHI Mgmt Group
- Who should be accountable for cloud identity governance when both developers and non-human identities need access?
- How should security teams prioritise identity governance when cloud, infrastructure, and application access are all changing at once?
- Who should be accountable for access governance when enterprises use a partner to implement identity controls?
- How should security teams evaluate SaaS access and license optimization in identity governance programmes?
