IGA Policies and Birthright Access: Rules That Grant Access Without a Request

The Monday nobody had to approve

On a Monday morning, David starts as a nurse on the cardiology ward of a private hospital. By the time he finishes his orientation coffee he can log in to the clinical workstation, open the electronic health record for patients on his unit, read the ward’s shared procedures, see his schedule, and send email. Nobody filed a request for any of it. No manager approved it. It happened because the HR system recorded that a person with the job code for registered nurse, assigned to cardiology, started that day, and the IGA platform had rules that turned those facts into access.

Those rules are policies, and this article is about them. The previous articles in this module covered the access people ask for (access request), the review of access they already hold (certification), and the bundles that access comes in (role engineering). Policies are the part that runs without anyone asking. They decide who gets which roles automatically, which combinations of access are never allowed, and what happens when the facts about a person change.

Policies are also where a program’s mistakes get expensive fastest. A bad approval affects one person. A bad rule affects everyone it matches, at the speed of the next synchronization with HR.

Three kinds of policy

IGA products use the word “policy” for many things, but most of what matters falls into three groups.

Assignment policies grant access when attributes match a condition. “Anyone whose employment type is employee gets the base workforce role.” “Anyone in department 4410 gets the AP Clerk role.” “Any registered nurse assigned to a unit gets read access to that unit’s patient records.” These are the rules behind David’s Monday.

Separation-of-duties policies say what nobody should hold at the same time: create a vendor and approve its payment, prescribe a controlled drug and dispense it, write code and approve its deployment to production. They don’t grant anything. They constrain everything else.

Lifecycle policies decide when access ends or gets re-examined: contractor access ends on the contract’s end date, accounts unused for 90 days are disabled, privileged entitlements expire after a set time. The JML article covered the events; lifecycle policies are the standing rules those events trigger.

The three interact all the time. An assignment rule grants a role, an SoD rule checks whether that role conflicts with something the person already holds, and a lifecycle rule decides when the role goes away. Most of the difficulty in policy design comes from those interactions, so the rest of the article spends more time there than on any single rule.

Assignment rules run on attributes, and attributes are only as good as their source

An assignment rule is a condition over identity attributes and an outcome. In most platforms it looks something like this:

WHEN  employment_type = "employee"
  AND department      = "Accounts Payable"
  AND job_code        IN ("4410", "4411")
THEN  assign business role "AP Clerk"

The logic is rarely the hard part. The hard part is that the rule is exactly as reliable as the attributes it reads. The identity data model article spent a long time on authoritative sources and data quality, and this is where that work pays off or doesn’t. If HR enters department names by hand and “Accounts Payable” sometimes appears as “Acct Payable” or “AP,” the rule silently skips those people. If job codes are reused for different jobs in different countries, the rule grants the wrong role to someone in a country nobody tested. If the location field is only updated when someone remembers, a nurse who transferred to oncology keeps reading cardiology records for months.

A few habits make rules much more robust. Write rules against coded values, like job codes and department IDs, rather than free-text names. Agree with HR which fields are reliable enough to drive access, and treat the others as informational only. And watch for the empty case: a rule that matches on department will match nobody whose department field is blank, which is often exactly the set of records that most need attention.

flowchart TD
  accTitle: From HR attributes to provisioned access through policy
  accDescr: The HR system supplies attributes such as employment type, department, job code, and location. Assignment rules evaluate those attributes and decide which roles the person should hold. Before anything is provisioned, the separation-of-duties policy checks the resulting combination against what the person already holds. If there is no conflict, the access goes to provisioning. If there is a conflict, the grant is held and sent to the policy owner for an exception decision.
  HR[HR attributes<br/>employment type, department,<br/>job code, location] --> AR[Assignment rules]
  AR --> R[Roles the person<br/>should hold]
  R --> SOD{SoD policy check<br/>against current access}
  SOD -->|No conflict| PROV[Provisioning]
  SOD -->|Conflict| EX[Held for exception decision<br/>by the policy owner]

Birthright: how small is small enough

Birthright access is the access a person receives for simply being part of a population: every employee, every contractor, every nurse. It’s the bottom layer of assignment policy, and it’s tempting to make it big. A large birthright bundle means fewer requests, happier new hires, and a quieter service desk in the first week.

It also means everyone in the population holds that access whether they need it or not, for as long as they’re in the population. Birthright access is rarely certified item by item (the certification article recommended excluding it, for good reason), so anything that lands there is effectively governed only by the rule itself. Over-generous birthright is privilege creep built into the design.

A test that holds up well: would every single person this rule covers use this access in their first month? Email and the intranet pass for all employees. The expense tool probably passes. The finance data warehouse doesn’t, even if half the company eventually gets access to it; that belongs in a role assigned by a narrower rule, or behind an access request.

In practice birthright usually comes in layers. A thin organization-wide layer covers everyone of a given employment type. A department or unit layer adds what that whole group needs. Beyond that, role-based rules and requests take over. David’s Monday is a good illustration. The hospital-wide layer gave him email, the intranet, and HR self-service. The nursing layer gave him the clinical workstation and the electronic health record with a nursing profile. The unit layer scoped his record access to cardiology. Each layer passes the “everyone in this group, from the first month” test for its own population.

Different populations, different birthright

Contractors and vendors need their own birthright, sourced from the vendor management system rather than HR, and it should be thinner than an employee’s. Many organizations give contractors no email by default and only the specific systems their engagement covers. Interns and seasonal staff are worth a separate look too, since a birthright designed for permanent staff often includes long-lived access that makes little sense for a three-month placement.

Service accounts and other non-human identities should have no birthright at all. They don’t belong to a population in the HR sense, and every piece of access they hold should trace back to a specific integration and an owner.

When attributes change: policy during a mover event

Assignment rules aren’t evaluated once at hiring and forgotten. They run again every time HR sends a change, and a mover event is simply the moment when a person’s attributes stop matching one set of rules and start matching another.

Take a nurse who transfers from cardiology to oncology. The unit rule for cardiology no longer matches, so its access should go. The oncology rule now matches, so its access should arrive. The question that sounds trivial and isn’t: in which order, and how fast?

Removing first and granting second is the safe choice whenever the old and new access could form a conflict. The JML article walked through exactly that case with Sara’s move into fraud review, where holding both sides for even a day would have opened a window for abuse. Granting first and removing later is kinder to the person moving, who might otherwise spend a shift without the access to do either job. Many programs end up with a per-rule setting: unit access in a hospital moves with a short overlap, often until the end of the current shift, because patient care can’t wait for a synchronization cycle; finance roles that touch payments remove first, always.

Whatever the order, the overlap should be short and deliberate. A “grace period” of 30 days for old access after a transfer is common, usually justified as handover time, and it’s one of the main ways mover access lingers far longer than anyone intended. If a handover period is genuinely needed, it should be a time-boxed exception with an end date, visible in the person’s access, not a silent default applied to every mover.

Rule-granted access and requested access need to be told apart

A person’s access arrives through different doors: some from assignment rules, some from approved requests, some from roles assigned by hand before the program existed. Policy logic needs to know which is which, because removal depends on it.

If a rule granted the oncology record access, the rule should take it away when the person no longer matches. If the same person had also requested access to an oncology research dataset, approved by its owner for a specific study, the unit rule has no business removing it when the person transfers; that access has its own justification and its own end date. Platforms handle this by recording the source of each assignment. Access that came from a rule is “owned” by the rule and follows it. Access that came from a request is owned by that request and follows its end date and its certification.

The common failure is a platform, or a migration, that loses the source. Every assignment becomes “assigned,” with no record of why, and the program can no longer let rules clean up after themselves without risking the removal of legitimately requested access. When you migrate into a new IGA platform, preserving or reconstructing the source of existing assignments is worth more effort than it usually gets.

Edge cases worth testing before go-live

Most rules work for the typical employee and break on the cases nobody thought about. A short list covers most of the surprises.

Rehires come back with a new employee record in some HR systems and the old one in others. If the old record is reactivated, rules may restore access from the person’s previous job years ago; if a new record is created, correlation may fail and leave the person with two identities. Leaves of absence, whether parental, medical, or sabbatical, are rarely terminations, but they shouldn’t leave full access active for six months either. Many programs suspend everything except HR self-service and email during a long leave and restore it on return.

People with two relationships to the organization trip up rules designed for one: an employee who also works a weekend shift through an agency, or a contractor who becomes an employee and briefly holds both records. And name changes, which should change nothing about access, sometimes trigger a delete-and-recreate in connectors that match accounts by name. Each of these is worth a test identity in the simulation environment before the rules go live.

Separation of duties as a policy object

The entitlement catalog article argued that separation-of-duties rules should be written against entitlements, not raw permissions or only roles, and the access request article showed one place those rules get checked. Making SoD work across a whole program means treating each rule as an object in its own right, with more to it than a pair of entitlement names.

A usable SoD rule records which entitlements conflict (two or more, sometimes across different systems), what the risk is in plain language, how severe it is, who owns the rule, and what exceptions are allowed and under what conditions. The owner is usually the business process owner, the person who can explain why “create vendor” and “approve payment” shouldn’t sit together and who can approve an exception with a compensating control when the business has no alternative.

The point of making it an object is that the same rule then gets checked everywhere access can change. It runs when someone requests access, when an assignment rule is about to grant a role, when a mover event combines old and new access, when someone edits a role’s content, and once more during certification as a backstop. A conflict that slips past one door gets caught at another. The next module covers SoD in depth, including how to build a conflict matrix and design compensating controls; here the concern is only how SoD fits next to the other policies.

When two policies disagree

Once there are dozens of assignment rules, a handful of SoD rules, and a few lifecycle rules, they will contradict each other. A department rule grants payment approval to everyone in treasury. An SoD rule forbids payment approval for anyone who can edit vendor records. One treasury analyst also holds vendor-master rights from a project last year. Which rule wins?

The answer has to be decided in advance and written down, because a platform left to its defaults will resolve the conflict in some way, often by rule order or by whichever rule was evaluated last, and nobody will be able to explain the outcome later. The convention most programs adopt is simple: a prohibition beats a grant. If an assignment rule would create an SoD conflict, the grant is held, not applied, and goes to the rule owner for a decision. An explicit, approved exception is the only thing that overrides a prohibition, and it carries an expiry date.

Two other conflicts show up often. Two assignment rules can grant overlapping access, which is usually harmless but makes it unclear which rule to change when the access should go away; a role that comes from two rules isn’t removed when only one stops matching. And a lifecycle rule can fight an assignment rule: the 90-day inactivity rule disables an account, the next HR synchronization sees the person still matches their department rule, and the account is re-enabled. Each of these needs a documented resolution, and the governance forum from the program roles article is the natural place to agree on them.

Simulate before you activate

Every policy change touches everyone it matches, which is the whole point of policy and also its main hazard. Changing the condition on a department rule from job_code IN ("4410","4411") to job_code = "4410" looks like a small cleanup. If 600 people carry code 4411, it removes a role from 600 people at the next synchronization.

Most IGA platforms can run a simulation, sometimes called a what-if or impact analysis, that evaluates a changed rule against the current identity data without applying anything. The output is the list that matters: who would gain which access, who would lose which access, and which new SoD conflicts would appear. Reviewing that list before activation catches the mistakes that are invisible in the rule itself, like a typo in a code, a department that was renamed last month, or a population nobody remembered the rule covered.

A reasonable routine treats every rule change like a small release. The change is written up with its intent (“give all cardiology nurses access to the new telemetry dashboard”). A simulation runs against production data. The rule owner reviews the simulated adds and removes, and anyone affected outside the intended population is investigated. Large changes go to the governance forum. And the change is activated at a known time, ideally not at 5 p.m. on a Friday, with someone watching the first synchronization.

Rollback deserves a thought before activation too. If a rule change removes access it shouldn’t have, restoring the previous version of the rule should restore the access at the next synchronization. That only works if rules are versioned and the previous version is kept, which is worth checking in any platform before you rely on it.

Building the first rule set

Programs rarely start with a clean sheet. Usually there are already roles, some from the role engineering work in the previous article and some inherited, assigned by hand to whoever seemed to need them. Turning those into rules is a gradual job, and a useful way to judge each candidate rule is to compare who it would match with who holds the role today.

Run the proposed rule as a simulation and lay its matches next to the role’s current members. People who appear in both are the easy part. People the rule matches who don’t hold the role today are either a gap the rule will close, which is good, or a sign the rule is too broad. People who hold the role but don’t match the rule are more interesting: some got the role by mistake and should lose it, and some do the job under a job code nobody expected, which means the rule needs another condition. A rule is ready to take over a role when that comparison has been walked through with the role owner and every difference has an explanation.

The order of work matters too. Start with the organization-wide birthright layer, since it affects everyone and is the simplest to get right. Move next to the largest, most stable populations, the same ones the role engineering article suggested starting with, where one rule replaces the most manual work. Leave small and fast-changing teams on access requests until their roles settle. And watch the access requests from each population for the first month after its rules go live; a request that shows up again and again from the same group is the clearest sign of something the rule should include.

Who owns a policy

Every policy needs an owner, for the same reason every entitlement and role does. Assignment rules are usually owned by the owner of the role they assign, since that person decides who belongs in it. SoD rules belong to the business process owner whose process the conflict would undermine. Lifecycle rules tend to belong to the IAM program itself, with compliance agreeing the thresholds.

Ownership comes with a review cadence. An annual review of each assignment rule asks whether the condition still describes the right population; organizations reorganize, rename departments, and introduce new job codes, and rules written against the old structure keep running long after the structure is gone. SoD rules are reviewed against the exceptions they’ve produced: a rule with dozens of open exceptions is either too broad or describes a process the business genuinely can’t separate, and both cases need a conversation rather than another exception.

Policies as evidence

Auditors ask a question that policies answer better than anything else in the program: why does this person have this access? For requested access, the answer is the request record. For rule-granted access, the answer should be just as concrete. This person matched rule AP-Clerk-02, version 4, on the date of their hire, because HR recorded job code 4410 in department 3100. The rule was approved by the head of finance operations, last reviewed in March, and its change history shows who altered it and when.

That chain only exists if the platform keeps rule versions and records which rule and version produced each assignment. When it does, sampling becomes easy for both sides. When it doesn’t, the program is left explaining that the access “came from a rule” without being able to show which rule, what it said at the time, or who approved it, and an auditor will reasonably treat that access as unexplained.

Worked example: birthright for a hospital nursing staff

A private hospital with 1,800 staff wants to stop provisioning clinical access by ticket. New nurses currently wait two to four days for access to the health record, borrow colleagues’ logins in the meantime, and the last privacy audit flagged that nurses keep access to their previous units’ patients after transferring.

The IAM team works with the chief nursing officer and the health record’s application owner. They agree on three layers. Every employee gets email, the intranet, HR self-service, and the training platform. Every registered nurse gets the clinical workstation login and the health record with a nursing profile, but no patient access yet. And each unit assignment adds read and charting access to that unit’s patients, driven by the unit code in the HR record.

The data work takes longer than the rules. Unit codes in HR turn out to be reliable for permanent staff but blank for float-pool nurses, who move between units by shift. Those nurses get a separate rule granting the float-pool profile, which gives access to patients on whichever unit they’re scheduled for, read from the scheduling system instead of HR. Agency nurses come from the vendor system with an engagement end date, and get the nursing and unit layers but no hospital email.

Before activation, a simulation runs the new rules against all 1,800 identities. It shows 43 nurses who would lose access they currently hold. Most are nurses who transferred units months ago, which is exactly the audit finding being fixed. Six are not: their unit codes were entered under an old numbering scheme that HR retired, and the rules would have cut them off from their current patients. HR corrects the six records before go-live.

SoD gets one rule in this scope. A nurse must not also hold the pharmacy role that verifies and dispenses medication orders, because one person could then both administer and account for controlled drugs. The rule owner is the director of pharmacy.

Three months later, new nurses have health record access on their first shift, transfers move access the day HR records the change, and the follow-up audit finds no nurse with access to a unit they no longer work on.

A shorter example: seasonal staff in retail

A retail chain hires 2,000 seasonal workers every November. Its birthright rule for store staff gives everyone the point-of-sale login, the scheduling app, and the company intranet, with no end date, because it was designed for permanent employees. Every February, the service desk spends weeks disabling accounts for people who left in January.

The fix is a lifecycle policy, not a different birthright. Seasonal staff are flagged by their contract type in HR, and their birthright carries an end date taken from the contract. When the season ends, access ends with it, and anyone extended into the new year gets a new end date from HR without anyone touching the IGA platform.

Common mistakes

Birthright bundles grow, almost never shrink. Each new tool gets added “because everyone will need it eventually,” and nobody removes the tool the company stopped using two years ago. Reviewing the birthright content once a year, with usage data, keeps it honest.

Rules are written against attributes nobody checked. The rule looks right, the data underneath it isn’t, and the first sign of trouble is a department’s worth of missing or extra access.

Policies are changed without simulation, which is how one edited condition removes access from hundreds of people overnight.

Precedence is left to the platform’s defaults, and conflicting rules resolve differently depending on evaluation order.

SoD rules exist on paper but are only checked in certification. A rule that runs only after the fact detects conflicts; to prevent them, it has to run wherever access is granted, including inside assignment rules.

What to measure

A handful of numbers show whether policy is doing its job. The share of new hires with complete access on their first day says whether birthright and assignment rules cover what people need. The volume of access requests in a population’s first month says what the rules are missing; if every new AP clerk requests the same report, it belongs in the role. The count of access granted by rules to people whose attributes no longer match, found by reconciliation, says how stale the data or the rules have become. And the number of open SoD exceptions per rule, along with their age, says whether each rule describes a real control or a process the business has quietly stopped respecting.

Two more are worth tracking once rules have been running for a while. One is the share of each population’s access that comes from rules rather than requests or manual assignment, which shows how far automation has actually reached. The other is the number of rule changes activated without a recorded simulation, which should be zero and usually isn’t the first time anyone counts.

Where this maps to standards

NIST SP 800-53 Rev. 5 touches policy in three places: AC-2 covers account management, including the conditions for group and role membership; AC-5 requires separation of duties to be defined and enforced through access authorizations; and AC-6 sets out the least-privilege principle that keeps birthright small. The model behind attribute-driven assignment rules is described in NIST SP 800-162, the guide to attribute-based access control. ISO/IEC 27001:2022 asks for the same discipline in Annex A 5.3 on segregation of duties, 5.15 on access control and 5.18 on access rights, which require access rules to be defined, applied and reviewed. And the SOC 2 Trust Services Criteria, in CC6.1 to CC6.3, expect access to be granted on the basis of defined roles and responsibilities and to change when they change, which is what an auditor will check when they ask how David’s access was decided.

Closing the loop

Policies are what let the governance decisions from this module run on their own. The roles designed in the previous article become useful when assignment rules hand them out from HR data. The SoD rules the catalog made possible become real when they’re checked at every door. And the access request process gets smaller, because most of what people need on their first day has already been granted by a rule someone reviewed once, simulated, and owns.

Recap

IGA policies are rules the platform applies on its own: assignment rules grant access from attributes, separation-of-duties rules forbid combinations, and lifecycle rules decide when access ends. An assignment rule is only as reliable as the attributes it reads, so it should use coded values, rely only on fields HR has agreed can drive access, and treat a blank field as a warning rather than a match. Birthright stays small and layered, organization first, then group, then roles and requests, and the test for every item is whether everyone it covers would use it in their first month, the way David used everything he received on his first Monday. When someone moves, each rule needs a decided order and any overlap should be short and visible, and every assignment should record where it came from so a rule only removes what it granted. Each separation-of-duties rule is an object with an owner, a severity and controlled exceptions, checked wherever access can change, and when a prohibition and a grant collide, the prohibition wins. And no rule change goes live without a simulation against real data that shows exactly who would gain and who would lose access.

Three questions to test yourself

1. A birthright rule gives every employee read access to the company’s data warehouse “because most people use it eventually.” What’s wrong with that, and where should the access live instead?
2. An assignment rule grants payment approval to the treasury department, and an SoD rule forbids payment approval for anyone who can edit vendors. One treasury analyst can edit vendors. Describe what should happen, and what would happen if precedence were left to rule order.
3. Why can a small edit to an assignment rule’s condition be riskier than approving a single privileged access request?

Hands-on exercise

Design the policies for one population you know well, such as a department at your workplace or a fictional branch office.

1. Write the birthright layers (organization, department, team) and justify each item with the “everyone, first month” test.
2. Write two assignment rules in the WHEN/THEN form shown above, and list the HR attributes each depends on and how reliable you believe they are.
3. Write one SoD rule as a complete object: conflicting access, risk, severity, owner, and allowed exceptions.
4. Describe how you would simulate a change to one of your rules and what you would look for in the results before activating it.