They should run internal discovery before writing the project plan. That means gathering pain points from business owners, documenting lifecycle failures, and ranking the highest-risk identity problems so scope is based on evidence rather than assumptions.
Why the First Move Is Discovery, Not Planning
When an IAM programme has not been scoped, the first job is to establish what is actually broken and where the pain is felt. That means discovery comes before the project plan: gather evidence from business owners, locate lifecycle failures, and separate urgent identity problems from nice-to-have improvements. Without that step, scope is usually built around assumptions, vendor defaults, or the loudest request in the room.
Internal discovery is not a light requirements exercise. It is the point where teams learn which identities are creating operational friction, which systems have hidden access dependencies, and which controls are failing repeatedly. For broad identity programmes, IAM and IGA Basics is the clearest foundation for distinguishing access management from governance work, and for understanding why scope has to reflect both current access and lifecycle state.
The practical payoff is sharper prioritisation. A programme that starts with discovery can identify patterns such as orphaned access, weak joiner-mover-leaver handling, overextended permissions, or poor ownership before those issues are translated into workstreams. That makes the eventual scope defensible, because it is grounded in observed risk and operational evidence rather than in generic maturity language.
What Discovery Should Capture Before Any Scope Is Written
The first discovery pass should focus on the identity failure modes that create the most business impact, not on every theoretical control gap. Business owners can usually tell you where access approvals stall, where deprovisioning is slow, where recertification is ignored, and where manual exceptions have become normal. Those are not just process annoyances, they are indicators of lifecycle weakness and governance drift.
A useful discovery output includes the affected population, the systems involved, the failure condition, and the business consequence. In practice, that means documenting who is struggling, which application or directory flow is responsible, what is breaking in the identity lifecycle, and what happens when the failure is not corrected. This is the information that turns a vague “improve IAM” request into a workable programme boundary.
Discovery also needs to separate structural issues from local noise. One team may ask for faster access requests, but the real problem may be missing role design, poor entitlement ownership, or no reliable offboarding trigger. Another may complain about audit findings, but the underlying issue may be stale accounts or inconsistent recertification. Treat those as evidence of root-cause categories, not as standalone feature requests.
For teams that need a lifecycle lens, NHI Lifecycle Management Guide shows the value of inventory, ownership, rotation, and offboarding as operating disciplines, while Lifecycle Processes for Managing NHIs reinforces that discovery must feed the full identity lifecycle, not just initial provisioning.
How to Turn Evidence Into a Scope That Can Actually Be Executed
Once the team has enough evidence, the next step is ranking. Not every identity problem belongs in the first phase, and not every complaint deserves equal weight. High-risk issues are the ones with broad blast radius, clear lifecycle failure, repeated manual work, audit exposure, or direct links to privileged or production access. Lower-risk items can be deferred if they do not materially change the control posture.
The easiest way to make this usable is to group findings into a few buckets: access governance, lifecycle automation, privileged access, visibility and inventory, and exception cleanup. That gives the programme a structure without pretending the scope is fully known on day one. It also helps sponsors see why some items are prerequisites, while others are later optimisation work.
A strong scope document should state what is included, what is explicitly out of phase one, and what evidence justified those decisions. That discipline matters because IAM programmes often fail when they try to solve authentication, governance, directory hygiene, and privileged access all at once. A discovery-first scope avoids that trap by anchoring the plan to measurable pain points and by sequencing work around the highest-risk control failures.
If the programme will eventually touch cloud or non-human access, discovery should include those populations from the start, because their lifecycle and privilege issues often amplify the same problems seen in human IAM. That broader lens is why What are Non-Human Identities and Cloud Workload Identity Guide are useful references once discovery starts revealing service accounts, workload credentials, or keyless access paths.
Risk and Threat Considerations
Starting with scope before discovery usually creates blind spots, especially where identity failures already affect production systems, privileged access, or deprovisioning. The risk is not just an inefficient programme, it is that the team formalises the wrong work first and leaves the highest-risk identities, entitlements, or lifecycle failures untouched.
Failure mechanism: Teams prioritise requested features instead of observed pain, so hidden issues such as stale access, weak ownership, or overprivileged accounts remain unaddressed while the programme is being built.
Impact: The IAM roadmap becomes harder to defend, remediation is mis-sequenced, and the organisation can continue operating with unresolved exposure in the identities that matter most.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | PM-11 — Mission and Business Process Definition | Discovery must tie IAM scope to business pain and mission impact. |
| CM-8 — System Component Inventory | Discovery depends on knowing which identities, apps and dependencies exist. | |
| AC-2 — Account Management | Lifecycle failures and ownership gaps are central discovery targets for IAM scope. | |
| Recommendation — Define identity work from mission-critical business processes before drafting the programme scope. Inventory identity-relevant systems and dependencies before planning remediation. Review account lifecycle failures and prioritise the highest-risk remediation items first. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Scope discovery needs an asset and identity inventory to avoid assumption-based planning. |
| A.5.15 — Access control | IAM scoping is driven by access problems, ownership and enforcement gaps. | |
| Recommendation — Build an inventory of identity-related assets before finalising the IAM programme scope. Translate discovered access failures into the initial control scope and priorities. | ||
| CIS Controls v8 | CIS-5 — Account Management | The question is about identifying account and lifecycle issues before planning. |
| Recommendation — Prioritise account and lifecycle discovery before implementing control changes. | ||
Practitioner Guidance
What to prioritise: Start with the identity problems that recur across business units, affect production or privileged access, or create audit and offboarding failures. Those are the issues most likely to justify early scope.
What to verify: Before you approve a project plan, verify that each major scope item is tied to a documented pain point, a named lifecycle failure, or an observed access risk. If you cannot point to evidence, treat the item as a candidate, not a commitment.
Decision rule: If an issue is frequent but low impact, keep it in the backlog; if it is high impact, cross-system, or tied to privileged access, bring it into phase one even if it is less visible politically.
Practitioner takeaway: Good IAM scope is discovered, not invented, and the best early programmes are the ones that convert real operational pain into a ranked set of identity problems before anyone writes the delivery plan.