How should organisations combine IAM governance with dynamic policy?

How should IAM governance and dynamic policy work together?

IAM governance should define who is allowed to exist in the system, what baseline access they hold, and who approves that access. dynamic policy should decide whether that access is usable at the moment of action, using context such as device state, location, risk signals, workload posture, or step-up requirements. The two layers solve different problems and should not be collapsed into one.

At the governance layer, the organisation needs durable controls for identity proofing, role design, entitlement ownership, segregation of duties, recertification, and exception handling. That is the audit layer, where you can explain why an identity has a permission and who is accountable for it. At the policy layer, the organisation can govern baseline entitlements and access reviews while still making a separate runtime decision about whether the request is acceptable in the current session.

Good implementations keep the governance model stable and the runtime decision adaptive. A role may grant the right to attempt an action, but dynamic policy can still deny or challenge that action if the session is coming from an unmanaged device, an unusual network, a sensitive data path, or a high-risk transaction. This separation is what lets teams keep administrative clarity without freezing access rules into static exceptions.

Where does the audit trail end and the runtime decision begin?

The audit trail should answer ownership questions: who approved the entitlement, why it exists, when it was last reviewed, and whether it still maps to job function or service need. Runtime policy should answer state questions: is this action safe right now, in this context, with this posture. If those two layers are blended, organisations usually end up with policy logic that is hard to explain and access reviews that no longer reflect reality.

The cleanest model is to treat IAM governance as the source of record for standing access and dynamic policy as the gate on use. That means role changes, joiner-mover-leaver events, and periodic recertification stay in the identity governance process, while contextual enforcement stays in the access path. An identity security programme should make this split explicit so teams know which control owns entitlement change and which control owns live enforcement.

This also improves investigations. When an access request is denied by context, the organisation can still show that the identity was properly entitled, while the policy engine rejected the live attempt. That distinction matters for support teams, auditors, and incident responders because it separates mis-governance from legitimate adaptive control.

What implementation pattern works best for least privilege?

The most effective pattern is baseline privilege plus contextual narrowing. Start with the smallest role or entitlement set that still allows the work to proceed, then let runtime policy narrow that access further when the request crosses a higher-risk boundary. That is more sustainable than trying to encode every business exception into static roles, which quickly creates role explosion and administrative drift.

For many environments, the strongest control model is a combination of IAM, IGA, and policy enforcement at the point of action. If the subject is cloud or workload-heavy, the same logic applies to service identities and machine access, where standing entitlements should be tightly scoped and runtime conditions should govern use. Cloud privilege right-sizing is a practical example of this model because it separates granted permissions from the permissions actually exercised.

One useful decision rule is this: if the control changes who may hold the permission, it belongs in governance; if it changes whether the permission may be exercised now, it belongs in dynamic policy. That rule prevents teams from overloading access reviews with operational context and prevents policy engines from becoming shadow IAM directories.

Risk and Threat Considerations

The main risk is false confidence. Organisations may approve a role or entitlement once and assume the resulting access is safe forever, even though the current session is running in a very different risk state. The opposite failure is equally common, where dynamic policy becomes so broad that it silently substitutes for proper entitlement governance and nobody can explain why access exists.

Failure mechanism: Static governance without runtime checks leaves permissive access available in unsafe contexts, while runtime policy without governance creates opaque, hard-to-audit access paths that are difficult to review or revoke cleanly.

Impact: The result is excessive privilege, inconsistent enforcement, weak auditability, and a larger blast radius when credentials, sessions, or privileged workflows are abused.

Practitioner Guidance

What to verify: Make sure every sensitive entitlement has an owner, an approval path, and a review cadence, and that every runtime denial can be traced back to a specific policy condition rather than an undocumented exception. If reviewers cannot tell whether a control failure is governance-related or context-related, the model is too blurred to trust.

Decision rule: Use governance for standing access, ownership, and recertification; use dynamic policy for session, device, location, transaction, or posture-based decisions. If you find yourself adding more and more exceptions to roles, or more and more permanent bypasses to policy, the design needs simplification.

Practitioner takeaway: The goal is not to make access fully static or fully adaptive, but to keep entitlement truth in governance and risk-sensitive enforcement in runtime policy so each layer stays explainable and effective.

Related resources from NHI Mgmt Group

• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Should organisations prioritise external exposure or internal credential governance first?
• How should organisations combine dynamic access checks with lifecycle governance?