Designing an Enterprise RBAC and SoD Governance Model

The problem

Access across in-scope applications was assigned directly, entitlement by entitlement, with no consistent role model in between. Two consequences followed. First, Segregation of Duties conflicts — someone able to both create and approve a payment, for example — went largely undetected, because nothing evaluated combinations of entitlements against a defined rule set. Second, access certifications were unreadable: reviewers were shown raw entitlement lists per user and, unsurprisingly, tended to approve everything rather than evaluate it, because the lists carried no business context.

Approach

The core of the work was defining a role-based access model and a Segregation of Duties rule set that business reviewers — not just IT — could actually reason about.

Roles were kept deliberately coarse-grained: a modest set of birthright roles tied to department and job attributes covered the common case, with anything beyond that handled through a governed access request rather than expanding the role model indefinitely. This was a direct reaction to role-mining data showing that a fine-grained role model, mapped one-to-one to existing ad hoc entitlement patterns, would have produced hundreds of near-duplicate roles — unmaintainable and no more meaningful to a reviewer than raw entitlements.

SoD rules were defined at the business-function level (e.g., “payment creation” and “payment approval”) rather than at the level of individual technical entitlements, and evaluated both preventively, at access request time, and detectively, against existing assignments. Certification campaigns were redesigned around the resulting role model, so reviewers saw role-level summaries with risk indicators instead of raw entitlement dumps.

Key decisions

• Coarse-grained roles, governed exceptions. Rather than modeling every existing access pattern as a role, the design covered the common case with a small role set and routed everything else through an approval workflow — trading some provisioning convenience for a role model that stays maintainable as the organization changes.
• SoD rules defined by business function, not raw entitlements. This made the rules interpretable by business stakeholders who needed to own and approve them, not just by the IT team implementing them.
• Certifications redesigned around the new model, not bolted onto the old one. Presenting role-based, risk-tiered summaries — rather than adding a role label on top of the same entitlement lists — was what actually changed reviewer behavior.

Challenges

• Role mining from years of ad hoc grants was messy. Existing access didn’t cleanly map to any obvious role structure; a meaningful amount of the effort went into deciding which access patterns represented a real role versus historical drift that shouldn’t be preserved.
• SoD rule ownership belonged to the business, not IT. Getting business stakeholders to define and stand behind the toxic-combination rules — rather than having IT define them unilaterally — took more coordination than the technical implementation.
• Migrating existing users without a disruptive cutover. Moving a large, active user base onto the new role model had to happen without breaking access for people mid-task, which meant a phased migration rather than a single cutover.

Outcome

SoD violations that had previously been invisible became visible, trackable, and assigned for remediation. Certification campaigns shifted from a compliance exercise reviewers rubber-stamped to a role-based review that gave reviewers enough context to make an actual decision. The role model also became the foundation the subsequent JML automation work built on, since birthright provisioning depends on a role structure that reflects how the organization is actually organized.