What breaks when organisations design IGA policies before discovery?

Policies built before discovery often target an assumed environment, not the real one. That leads to mis-scoped approvals, review cadences that miss actual risk, and controls that have to be rewritten after the inventory surfaces shadow IT, dormant accounts, or lifecycle gaps. The result is resentment, wasted effort, and slower governance because the program keeps retrofitting its own assumptions.

Why This Matters for Security Teams

When IGA policies are written before discovery, the program is usually optimizing for an inventory that does not yet exist. That creates a false sense of control: approvals are mapped to guessed ownership, review periods are assigned without knowing actual usage, and exceptions are treated as temporary even when they reflect how systems really run. NIST’s NIST Cybersecurity Framework 2.0 emphasizes knowing assets and governing risk continuously, not by assumption.

For non-human identities, the gap is sharper. NHIs often outnumber human identities by 25x to 50x, and only 5.7% of organisations have full visibility into their service accounts, according to NHIMG’s Ultimate Guide to NHIs. If discovery happens after policy design, the policy almost always lands too broad in some places and too narrow in others, which is how governance becomes busywork instead of risk reduction. In practice, many security teams discover that their first policy draft was really just a guess after the first access review exposes the real estate.

How It Works in Practice

Discovery should define the policy boundary, not merely validate it. Before teams set IGA controls, they need an inventory of identities, owners, entitlements, system dependencies, and the real business purpose behind each account. That means discovering service accounts, API keys, automation identities, and dormant credentials first, then shaping approval paths and certification rules around what actually exists. NHIMG’s NHI Lifecycle Management Guide is useful here because lifecycle state is often where hidden risk becomes visible.

In practice, a working sequence usually looks like this:

• Inventory all identities and classify them by human, NHI, system, or vendor-owned use.
• Map each identity to a named owner, technical steward, and business function.
• Identify where entitlement data is incomplete, stale, or inherited from legacy tools.
• Build policy rules from observed patterns, not from assumed job roles alone.
• Set review cadences based on risk, connectivity, and privilege rather than a fixed calendar.

That sequencing matters because IGA controls depend on accurate scope. NIST SP 800-53 Rev. 5 reinforces the need for account management, access enforcement, and ongoing review, but those controls only work when the underlying identity set is known. NHIMG also notes that 71% of NHIs are not rotated within recommended time frames, which shows how easily lifecycle gaps persist when governance starts too early and then has to be rewritten around the true environment. These controls tend to break down in hybrid estates with shadow IT and unmanaged automation because the inventory is never stable long enough for static policy assumptions to hold.

Common Variations and Edge Cases

Tighter discovery-first governance often increases rollout time, requiring organisations to balance speed against accuracy. That tradeoff is real, especially when teams want quick wins from an IGA platform before data quality is mature. Current guidance suggests resisting the urge to publish permanent policy until discovery is at least good enough to distinguish active, dormant, orphaned, and high-risk identities, but there is no universal standard for exactly how complete that discovery must be before policy drafting begins.

Some environments need a phased approach instead of a clean sequential one. For example, highly regulated teams may define interim controls for the highest-risk systems while discovery continues elsewhere. Others may use temporary policy exceptions for known unknowns, but those exceptions should expire automatically and be revisited after inventory reconciliation. The main edge case is when legacy platforms cannot expose reliable identity data at all. In those cases, policy must be conservative and compensating controls become more important than elegant rule design. NHIMG’s Regulatory and Audit Perspectives section is especially relevant where auditors expect evidence of control design, yet the operational environment still contains unclassified identities. The practical failure mode is simple: policies written too early become bureaucratic artifacts that nobody trusts once discovery proves the environment was different all along.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on document imaging for remote onboarding?
• Why do non-human identities create compliance risk even when policies exist?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?