SECURITYATLAS✳

✳ The reference desk / In practice

IGA

Processes and tools for reviewing who should have which access and removing what is no longer justified.

Identity governance and administration

What it means

Identity governance and administration asks who should have access, why they should have it, who approved it, and when it should end. It connects business responsibility to account and permission administration. Request workflows, access reviews, role design, and removal of unjustified access are typical parts of the capability.

The quality of the decision matters more than the number of approvals collected. A reviewer needs to understand what a permission allows and whether it fits the person's current work. Governance becomes effective when an approved removal reaches the target system and someone verifies the result, rather than ending with a checked box.

The idea at a glance / Identity

An approved removal can leave access unchanged.

Keep the current job, inherited permission, owner decision and unfinished application work together.

Synthetic U162 moved from payables to planning. A trusted role record now justifies budget-report reading, not supplier-detail changes. In FinanceDesk, old group G162 still grants that change while a direct grant permits budget reading. Owner Sam records D162 to remove the old group access; Q162 is queued for Maya. The connector has not applied it.

IGA: Keep the current job, inherited permission, owner decision and unfinished application work together. The explanation below describes the relationships.U162 · role change and owner reviewDecision retained; target still unchangedTrusted current role · planningNeeds budget read, no payee editRole mapping assumed accurateFinanceDesk · effective accessG162 still permits supplier editDirect budget-read grant remainsSam · owner decision D162Remove old G162 membershipQ162 queued; Maya has not appliedControlled application checksSupplier update still succeedsBudget read works · removal openREMOVAL APPROVED · ACCESS REMAINS

READ THE PICTURE

Decision beside effective access

Sam approves removal of G162, but Q162 is still queued. U162’s controlled supplier-detail update still succeeds; budget reading remains permitted.

Keep in mindRole mapping, owner authority and effective grant records are assumed accurate for this snapshot. D162 is a decision, not an applied permission change. This selected application check does not cover every inherited route, other applications or existing sessions elsewhere. No real supplier or payment data is used.

Read the complete example
  1. Decision beside effective access. Sam approves removal of G162, but Q162 is still queued. U162’s controlled supplier-detail update still succeeds; budget reading remains permitted. The authoritative role record says U162 now works in planning. FinanceDesk’s direct budget-read grant remains appropriate; membership in old payables group G162 still inherits supplier-update permission. Sam’s owner review D162 names that exact membership for removal and records why. Q162 is queued for Maya, with no connector application or verification recorded. An isolated SQL-backed supplier-detail update still succeeds through G162, while a budget-read control succeeds. The synthetic original record and decision remain available. Clearing a direct permission would not remove the inherited grant. This is unfinished governance follow-through, not an assertion that every permission was collected or removed.

Role mapping, owner authority and effective grant records are assumed accurate for this snapshot. D162 is a decision, not an applied permission change. This selected application check does not cover every inherited route, other applications or existing sessions elsewhere. No real supplier or payment data is used.

Diagram references: NIST SP 800-53: account reviews, privilege and dynamic access · OWASP: enforce permission on every request

AN ILLUSTRATIVE SCENARIO

A review decision and an unapplied task

U162 moved from payables to planning. FinanceDesk still inherits supplier-update permission through G162, alongside a justified direct budget-read grant. Owner Sam records D162 for group removal, but connector task Q162 is still queued. A controlled update still succeeds through the inherited grant. Budget reading remains permitted; implementation and verification are unfinished.

Put it to work

  1. Connect identities to an authoritative record of their role, sponsor, and status, including contractors and nonhuman identities with named owners.
  2. Provide reviewers with understandable permissions, recent relevant context, and a clear retain-or-remove decision; prioritize access with significant consequences.
  3. Track each removal through implementation and verification, and revisit role designs that repeatedly grant more access than people need.

How to check your work

Sample a completed review and compare its decisions with current application permissions. You should be able to show that retained access has a reason and removed access is actually unavailable.

Connect the ideas

  • IAM

    The capability for creating identities, authenticating them, authorizing actions, and managing their lifecycle.

  • Privilege creep

    The slow accumulation of standing access after the original job that justified it has ended.

  • Least privilege

    Granting each identity only the actions, objects, and time window required for the current job.

  • PAM

    Controls that broker, record, and constrain powerful administrative identities and sessions.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.