A quarterly review begins with over 10,000 entitlements attached to it. Somewhere in there are probably 400 that nobody would grant again today. But every line looks the same: an account, a group name, a date. So the access certification gets approved in bulk, the evidence gets filed, and the exercise produces audit evidence rather than a decision that makes any meaningful changes. This is the mechanism behind what we described in Stop Rubber-Stamping Access Reviews.
Don't put the blame on the reviewer. Approving everything is the rational response to a list with partial data.
Normal already exists in your data
Every organization already knows what normal access looks like for a given job. And this should not have to be written down to be measurable. If 96 percent of the people with the same job title and department have access to the ERP system, that access is normal. Not because a documented policy says so, but because the organization has been behaving that way for years and the pattern is sitting in the data.
The four percent who do not have the same access to the same systems is THE gap.
What Hydden does with that
Hydden derives job functions from attributes already on the owner records it collects, like department, title, and location. For each job function, Hydden calculates the percentage of accounts that have a given group membership and entitlement. When that share clears a configurable threshold, Hydden writes a policy that this access is normal for this job function. Anyone in the function without it is a gap. Anyone outside the function who has it is an outlier.
Job functions are derived from owner attributes, where department and title combine into roles like engineering-senior_engineer. The policy threshold, set to 75%, is the share of a job function that has to hold an access before it counts as normal.
A policy is auto-generated for the QA_Engineering job function from an analysis of all owner accounts. The rule states its own basis in plain terms: users with this role commonly have access to this application.
When a review campaign runs, entitlements matching those policies are approved automatically and the rest go to a human. The reviewer receives the exceptions, with the account details, the classification, the resolved entitlements and the previous decision on that account if there was one.
What reaches a reviewer: the factors that flagged it, the entitlements resolved behind it, and the decision made on the same account in the previous campaign.
The policies are continuously regenerated from the data, so they describe the organization as it currently operates rather than as it was structured when someone last ran a role-design exercise.
Two things this depends on
It depends on knowing who owns each account. A job function is an attribute of a person, so an account nobody can attribute to a person cannot be compared to anything. Deriving normal access is downstream of resolving accounts to owners, which is why this mechanism belongs to a record rather than to an IGA review tool.
It measures what is common, not what is correct. If everyone in a job function has more access than they need, that over-provisioning is what the data says normal looks like, and the policy will reflect it. Deriving normal from observed behavior ensures reviewers pay attention to the ones that matter. It does not rightsize the access. That is what Hydden's entitlement analysis is for. More on that in an upcoming blog.
The exceptions surfaced by this method are genuine outliers within the organization's own patterns, which is a much shorter and more defensible list than a policy engine's opinion about what a role should contain. That is the IGA gap: the workflow runs on data the governance platform does not hold.
This allows you to move from scheduled quarterly access reviews to triggering an approval when access changes, which requires holding the change history that occurred on every account.
Hydden derives these outlier numbers from the identity data it already collects and routes only the exceptions to a human owner. To see what your last review would have looked like with the pattern separated from the outliers, schedule a demo.
Frequently asked questions
What is a job function in this context?
A combination of attributes observed on owner records, department and title by default, extensible to fields like country. It is derived from the data rather than authored, so it reflects how the organization is currently arranged rather than an intended structure.
How is this different from role-based access control?
Role-based access control defines what a role should contain and then provisions against that definition. This measures what people in a job function actually hold, and uses the result to decide which entitlements need a human decision. One is a design exercise, the other is a way of allocating reviewer attention across a list too long to read.
What threshold decides that access is normal?
It is configurable. The point of the threshold is that it is yours: setting it higher sends more entitlements to a human, setting it lower approves more automatically, and the right setting depends on how much reviewer time an organization has and what its auditors expect to see.
Does this reduce the audit evidence a review produces?
No. Auto-approved entitlements are recorded as decisions with the policy that approved them, so the evidence shows what was approved, on what basis, and which items a named human decided individually.
What happens to accounts with no owner?
They cannot be compared to a job function, so they go to a human. An account holding entitlements with nobody accountable for it is a finding in its own right, and it is one of the more common things a first collection turns up.