An entitlement is a single grant: a role, a group, or a permission that lets one person do one thing in one system. Entitlement management is how those grants get requested, approved, time-boxed, and reviewed, so each person holds the access their job needs and nothing more. Get that right and least privilege stops being a slogan and becomes something you can produce evidence for.
An entitlement is the atomic unit of access. A role bundles permissions for a job function. A group confers access by membership. A permission is the single right to read a record, run a job, or push to production. Entitlement management is the governance layer over the whole set of grants across your estate: who holds what, on what justification, and until when.
Keep it distinct from two neighbors. Identity lifecycle management governs the arc of the person, joiner to mover to leaver. Deprovisioning governs clean removal. This page is about the grant itself, the thing in the middle that accumulates quietly between those events. The runtime side of it, the system deciding whether a given account may perform a given action, is access enforcement, control AC-3 in NIST SP 800-53. Everything below is about deciding which entitlements should exist in the first place, and keeping that decision honest over time.
The person opens a catalog of defined entitlements, picks the specific one they need, and states a business reason. The request routes to someone accountable for that resource, ideally the manager plus the resource owner, not whoever happens to pick up the queue. The approver sees the justification and the access being asked for, and the grant is issued with an expiry attached.
Three things make this different from a ticket. The request maps to a named entitlement rather than a prose description, so the grant is precise. The approver is accountable for the resource, so the yes or no means something. And the grant is time-bound, so it does not become permanent by default. SOC 2 criterion CC6.3 expects exactly this shape: access authorized, modified, and removed by role, with least privilege and separation of duties in view.
Least privilege is the principle that each person, service, and account holds only the access the job requires, for only as long as it is required. NIST SP 800-53 defines it as control AC-6. The failure mode it guards against is standing access: grants that sit open indefinitely because nobody scheduled their removal.
Privilege creep is standing access compounding. Change teams, keep the old access, repeat, and a mid-career employee holds a set of entitlements no one person was ever meant to have.
Two moves cut standing exposure. Scope each grant to the smallest entitlement that satisfies the request. And prefer time-bound or just-in-time access over permanent grants, so access that stops being used also stops existing. The goal is not zero access. It is the smallest set for the shortest time, with an expiry doing the cleanup instead of human memory.
Separation of duties splits a sensitive process across more than one person, so no single account can complete it alone. NIST SP 800-53 covers it in control AC-5, where it is titled "separation of duties." Audit and SOX practice call the same idea segregation of duties, so you will see both names for one control.
In entitlement terms, the risk is a toxic combination: two grants that are each reasonable alone but dangerous together. The account that can create a vendor should not also approve its payments. The person who submits an expense should not approve it. The engineer who writes the code should not be the only one who can deploy it to production. Separation-of-duties policy names these conflicting entitlement pairs once, then enforces them in two places: at request time, where the conflict is flagged or blocked before the grant is issued, and at review time, where existing conflicts surface for remediation. Where a conflict is unavoidable, the answer is a documented compensating control, not silence.
Even a clean request path leaks over time, because jobs change and grants outlive their reason. Entitlement review, or recertification, is the recurring check that closes that gap. On a set cadence, a reviewer looks at each grant a person holds and attests that it is still needed. Anything not affirmed is revoked. A sensible default is quarterly review for privileged and high-risk entitlements, at least annual review for the rest, and an event-driven review whenever someone changes roles.
Two design choices decide whether recertification is real or theater. Bias to removal on non-response, so an ignored review revokes access rather than rubber-stamping it. And give reviewers the context to decide, the entitlement, the person, the last use, and any separation-of-duties conflict, rather than a bare list of names. It also maps to SOC 2 CC6.1, logical access to protected assets.
Run recertification campaignsThe share of access granted through the governed request path versus out of band. Anything off the path is invisible.
The share of grants that are time-bound versus standing, and the median grant duration.
Active separation-of-duties conflicts and how long they stay open before remediation or a documented control.
Review completion and revocation rate, and mean time from request to grant. A slow path is why people route around it.
Turn entitlement reviews into evidence, not a spreadsheet.
Try access certification