Updated recently
Last updated:
Quick Answer: SailPoint IIQ policies are how access rules become enforced behaviour: policy types evaluate identities, roles and entitlements to detect violations (segregation of duties), enforce business requirements (who may request what) and drive role-based access. Policies are data plus optional BeanShell logic, executed by policy scans at request time, refresh time or scheduled. The hard part is never the mechanism — it is keeping the policy data truthful as the business changes, which is why the maintenance rhythm below matters more than the initial design.
The Policy Types and Where They Enforce
| Policy type | What it checks | Where it typically runs |
|---|---|---|
| Segregation of Duties (SoD) | Forbidden combinations of entitlements/roles on one identity | Request approval, refresh, scheduled scans |
| Business Role Mining / Requirements | Whether role assignments match documented rules | Role assignment, refresh |
| Entitlement-based policies | Attribute or entitlement conditions (e.g. privilege level by job code) | Request, refresh |
| Custom (BeanShell) policies | Anything the rule engine can express when stock checks cannot | Wherever attached; slowest, use sparingly |
Enforcement points matter more than most training admits: a policy that only runs in nightly scans detects violations after the fact; the same policy wired into request approval prevents them. Prevention belongs in request flows; detection belongs in schedules. Design both, and know which one you are looking at when a violation appears.
SoD in Practice: The Data Is the Design
An SoD definition names a policy, lists the toxic combinations (entitlements or roles that must not coexist), and optionally defines mitigating controls. The mechanism takes a day to learn. The discipline takes forever, and that is the real job:
- Sourced from the business, not the tool: the combinations come from control owners and audit requirements. IIQ enforces; it does not decide.
- Versioned and reviewed: policy data changes with regulations and reorganisations. Undocumented policy edits fail audits as thoroughly as missing policies.
- Tiered by risk: hundreds of low-risk combinations produce noise; the dozen that matter get lost. Rank enforcement strength accordingly.
RBAC and Policies: How They Interlock
Business roles in IIQ represent job functions; role assignment can be driven by rules (birthright by attribute) or by request. Policies then police the results: a role might grant the entitlements a payroll analyst needs, while an SoD policy ensures the same person cannot also hold payment-approval rights. When role design and policy design happen in different rooms, you get the classic failure: roles that cannot be assigned without violating policy. Run the designs as one conversation, with shared artefacts: the role-to-policy matrix, the toxic-combination list with business owners, and the exception register reviewed quarterly. The campaign guide covers how reviews catch what policies miss.
When Policies Flood the Teams
A shared-services client enabled broad SoD scanning on every refresh. Morning queues showed 1,900 “violations” — 1,840 of them false positives from an entitlement mapping that had drifted after an application upgrade. Two fixes followed: the mapping (data), and the scan scope (design). The enduring rule from that incident: tune detection precision before granting policy authority. A noisy policy engine gets disabled by management within a quarter, and then you have no policy engine at all. Budget a tuning cycle after every application upgrade for exactly this reason: entitlement mappings drift, scans flag the drift, and an unowned noise spiral starts within days.
Writing a Custom Policy Rule (and When Not To)
Custom BeanShell policies handle genuinely organisational logic — for example, “contractors in country X cannot hold any entitlement above level 3 outside their business unit.” A skeleton, with the guardrails the code review will demand:
import sailpoint.object.Identity;
import sailpoint.tools.Message;
String empType = identity.getStringAttribute("empType");
String country = identity.getStringAttribute("country");
if ("CONTRACTOR".equals(empType) && "IN".equals(country)) {
// Iterate granted entitlements; flag level-4+ items
// Return a violation with a human-readable message
return new Message(Message.Type.High,
"Contractor " + identity.getName()
+ " holds a level-4 entitlement in " + country);
}
return null;Reserve custom rules for logic stock policy types cannot express — they run more slowly, are harder to audit, and often mask a data problem that entitlement mapping should have fixed. The BeanShell examples guide shows more rule contexts.
Policy Change Management
Policies govern access, but policies themselves need governance — a point most teams learn the hard way, usually in the quarter when a reorganisation doubles the toxic combinations overnight. The pattern that survives audits: every new toxic combination or policy change goes through a lightweight review (proposer, business owner of the affected entitlements, security sign-off), lands with a documented effective date, and carries a named owner. Version-control the policy data exports alongside your rule code, because “what did the policy say in March” is an audit question with a real answer or an uncomfortable one. When an SoD combination changes (reorganisations do this constantly), run a delta scan before the change goes live so you know how many identities the new rule will flag — walking into the review with that number is the difference between policy authorship and policy theatre. The IGA fundamentals guide frames where policies sit in the wider control model, and the change discipline above is usually what separates estates that pass audits from estates that survive them. Treat the discipline as part of the policy itself — an unowned policy is a liability wearing a control’s clothes.
Training Resources
Policy labs — including an SoD enforcement exercise wired into request approval — are part of the SailPoint IdentityIQ Certification Training. For the request-side mechanics, see the identity request lifecycle; for the full skill map, the IIQ roadmap; and the IAM training track for governance beyond SailPoint.
FAQ
What are the policy types in SailPoint IIQ?
Core types include Segregation of Duties, business requirement/mining policies, and entitlement-based policies, with custom BeanShell policies for logic the stock types cannot express. Each attaches to enforcement points: request approval, refresh or scheduled scans — the enforcement point matters as much as the rule, since the same policy prevents at request time and merely detects at scan time. Wire prevention for the combinations that would embarrass you in an audit; let detection handle the rest.
How does SoD work in IIQ?
You define toxic entitlement or role combinations as policy data; IIQ evaluates identities at scan/request/refresh time and flags violations. Enforcement strength depends on where you wire the policy — request-time checks prevent, scheduled scans detect — prevention beats detection for exactly the reasons the flood story above shows.
Can IIQ block an access request automatically?
Yes — request-stage policy evaluation can reject or flag a request before approval completes. Most organisations allow documented mitigation exceptions with owners and expiry dates rather than absolute blocks for every combination — the exception register is itself audit evidence when it is maintained, and a liability when it is not.
Why do we get so many false SoD violations?
Usually stale entitlement mappings after target-system changes, over-broad policy data, or duplicate entitlements across applications. Fix the data and scope the scans precisely before adding new policy combinations — every false positive spends reviewer trust you will want later.
Should policies run in refresh or only in scheduled scans?
Both, deliberately: request-time and refresh enforcement for the combinations that must never coexist, scheduled scans for detection, reporting and drift. Running everything on every refresh needs the scan performance to justify it — most teams discover the cost in the quarterly slowdown before they discover it in a design review.
