Who should be accountable for defining IAM requirements in a new programme?

Accountability should sit with identity, security, and the business owners who depend on access outcomes, not with the PMO alone. The programme is governing access to services and data, so the people affected by those access decisions must help define the requirements and risk priorities.

Why This Matters for Security Teams

IAM requirements for a new programme are not just a technical backlog item. They define who can access systems, what can be changed, how exceptions are approved, and how quickly access is revoked when risk changes. If those requirements are owned only by the PMO, the result is often process completeness without operational fit. Security, identity, and business owners must align on outcomes because access decisions affect fraud exposure, service continuity, audit evidence, and incident response.

Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that access control is a shared governance concern, not a documentation exercise. NHI programmes fail fastest when requirements ignore how secrets are issued, rotated, and revoked in real workflows. NHI Mgmt Group research shows that 79% of organisations have experienced secrets leaks, and 96% store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which shows how quickly weak requirements become operational exposure. See Ultimate Guide to NHIs and Azure Key Vault privilege escalation exposure for the practical failure patterns.

In practice, many security teams encounter access sprawl only after a service account or API key has already been abused.

How It Works in Practice

The accountable group should define IAM requirements as an operating model, not a single policy document. Identity and security teams typically own the control design, business owners define the access outcomes needed for delivery, and application or platform teams explain technical constraints. That division matters because access requirements for a customer portal, data pipeline, or agentic workflow are rarely identical even when they sit in the same programme.

A workable approach starts with a requirement set that answers five questions: who or what needs access, what resource is being protected, what action is allowed, how long access should last, and what evidence is needed to approve or revoke it. For NHIs, that usually means defining workload identity, secret handling, rotation triggers, and offboarding from day one. NIST’s access control guidance and Security and Privacy Controls are useful here because they force explicit control ownership rather than assuming the implementation team will infer it.

In NHI programmes, requirements should also specify:

• Whether secrets may exist at all, or whether workload identity and short-lived tokens are mandatory.
• Who approves standing privilege, and what exceptions require time-bound review.
• How service accounts are inventoried, monitored, and revoked when systems are retired.
• What logs are required to prove access use, rotation, and failed attempts.

This is where NHIMG research is especially relevant: if 91.6% of secrets remain valid five days after notification, then revocation and ownership need to be requirements, not downstream cleanup. The failure mode is visible in incidents like TruffleNet BEC Attack — Stolen AWS Credentials, where credential sprawl and slow containment amplified impact. These controls tend to break down when ownership is split across too many teams because no single group is accountable for the full access lifecycle.

Common Variations and Edge Cases

Tighter IAM governance often increases delivery overhead, requiring organisations to balance speed against control depth. That tradeoff is real in programmes that span cloud, legacy, partner access, and AI-driven automation, because each environment has different identity primitives and approval paths.

There is no universal standard for who should sign off every IAM requirement, but best practice is evolving toward a shared accountability model with clear decision rights. In smaller programmes, one security architect may coordinate the requirements. In larger initiatives, an identity product owner, a business sponsor, and a risk owner often need to co-own the decisions. The PMO can track milestones, but it should not be the only authority defining access rules, exception handling, or revocation expectations.

Edge cases are common when:

• Third parties or vendors need access, which adds contract and offboarding requirements.
• Legacy apps cannot support modern federation, forcing compensating controls.
• Automation pipelines or service accounts outnumber human users, making NHI governance the dominant risk.
• AI agents or autonomous workflows need tool access, where static RBAC alone may not reflect runtime intent.

For that reason, the accountable owner should ensure the requirement set is testable, auditable, and mapped to control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls and the organisation’s NHI governance baseline in Ultimate Guide to NHIs. When identity ownership is not explicit, the first sign is usually an audit gap or a leaked secret, not a failed design workshop.

Related resources from NHI Mgmt Group

• Where does cross-environment agent discovery fit in an IAM programme?
• Who is accountable for MCP traceability under AI governance requirements?
• Who is accountable when a homegrown IAM process fails an audit or leaves access active too long?
• Who is accountable when IAM governance depends on bolt-on systems?