How should organisations scope an identity and access governance programme before they start implementation?

Why This Matters for Security Teams

An identity and access governance programme fails fastest when it is scoped as a policy exercise instead of an operating model. Teams often start with entitlement reviews or tool selection before they have mapped where identities exist, who owns them, how access is requested, and which business processes depend on them. That creates blind spots in privileged access, service accounts, and third-party connections, which are precisely where risk tends to concentrate. NHI Management Group notes that only 5.7% of organisations have full visibility into their service accounts, which is why a discovery-led scope is not optional. See also the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0 for the governance-first framing.

Good scope work separates what must be controlled immediately from what can wait for a later phase. It also forces alignment between compliance obligations, operational maturity, and stakeholder readiness, so security does not promise coverage the business cannot sustain. In practice, many security teams encounter entitlement sprawl and hidden exceptions only after audit pressure or a breach review has already exposed the missing inventory.

How It Works in Practice

The most defensible scope starts with an inventory of identities, applications, data flows, and approval paths, then layers governance around the highest-risk processes first. For human access, that usually means joining joiner-mover-leaver events, privileged roles, and sensitive systems. For non-human identities, the baseline has to extend further: service accounts, API keys, OAuth apps, certificates, CI/CD secrets, and machine-to-machine trust relationships. The OWASP Non-Human Identity Top 10 is useful here because it highlights the failure modes that arise when identities are treated as static accounts rather than operational dependencies.

A practical scoping workshop usually answers four questions:

• Which business services depend on identity controls to function safely?
• Which systems already have authoritative ownership, and which do not?
• Where are credentials stored, rotated, approved, and revoked today?
• Which controls are required for compliance, and which are needed for resilience?

From there, the programme scope should define governance domains, not just tools: access request and approval, privileged access, secrets lifecycle, periodic review, offboarding, exception handling, and evidence collection. Current guidance suggests scoping by risk tier and control maturity, then expanding coverage in increments rather than forcing a full-enterprise rollout on day one. NHI Management Group’s Top 10 NHI Issues is a useful reference for where inventory gaps and over-privilege usually appear first. These controls tend to break down when ownership is split across infrastructure, application, and platform teams because no single team can confirm the authoritative source of access truth.

Common Variations and Edge Cases

Tighter governance scope often increases coordination cost, requiring organisations to balance control depth against delivery speed. That tradeoff is especially visible in federated enterprises, fast-moving engineering environments, and acquisitions where identity data is fragmented across multiple directories and cloud tenants. In those settings, best practice is evolving rather than settled, and there is no universal standard for how much exception handling should sit in the first phase versus later operational maturity.

For high-risk environments, the scope may need to include third-party access, delegated administration, and machine identities from the start, especially where a vendor or automation pipeline can reach production. NHI Management Group research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes external trust a scoping issue, not just a monitoring issue. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is helpful when the programme must satisfy both security and audit evidence requirements. The main edge case is a highly decentralised engineering organisation with self-service tooling, because control design can fail if it ignores developer workflows and introduces governance that cannot be adopted operationally.

Related resources from NHI Mgmt Group

• Should organisations prioritise simplification before expanding identity governance scope?
• Should organisations use AI for identity governance before they clean up data and policies?
• How do organisations evaluate whether they need one platform for both data access and identity governance?
• Who is accountable for identity governance when organisations shift production, suppliers, and workloads in response to disruption?