Role Engineering: Top-Down, Bottom-Up, Hybrid, and Role Mining

Eleven clerks and a copied profile

Sara López runs finance operations at a regional insurer, and her last audit came back with a finding she can’t explain. Several people in accounts payable can create a vendor in the ERP and also approve payments to it. Nobody remembers granting that combination. New hires on her team get their access by copying a colleague’s, the colleague got theirs the same way, and after enough years of copying, the access no longer describes any job anyone designed. The auditor’s recommendation is one line long: “define roles.” Doing that properly takes most of this article, and we’ll come back to Sara’s team when the pieces are in place.

The first thing to sort out is the word itself, because this domain has used “role” in two ways so far. The entitlement catalog article defined a role as a named bundle of entitlements assigned to a population: Accounts Payable Clerk, with its invoice entry, purchase order matching, and vendor lookup. The article after it, on roles in an IGA program, set that meaning aside on purpose and used the word the way everyone outside IAM does, as a person’s job: the architect, the business analyst, the application owner, the compliance officer.

Role engineering is where the two meanings meet. The roles being engineered are bundles, in the catalog’s sense. But each bundle is supposed to mirror a real job in the organization, and the work of building it is done by the people from article 5. The business analyst runs the interviews. The application owner decides what goes into each system’s piece of the bundle. The architect sets the structure, compliance checks it against separation-of-duties policy, and the governance forum approves it. A role in the access sense is, in the end, a written-down answer to “what does this job need?”, produced by people whose own jobs are defined by the program.

Keeping both senses in view makes the rest of the article easier to follow. When a role design goes wrong, the cause is almost always a mismatch between the bundle and the job it claims to represent, or a gap in who was responsible for keeping them aligned. Sara’s audit finding is that mismatch in its purest form: bundles that drifted away from any job because nobody owned them.

From RBAC as a model to roles as a program

The access management domain already covered role-based access control as a model. Users are assigned roles, roles carry permissions, and checking access becomes a matter of checking role membership. That article explained how roles work. An IGA program runs into a different question in its first month: what should our roles actually be?

It sounds like a design exercise you do once. In practice it never ends. Someone has to decide which forty entitlements go in the clerk role, whether the clerk in the Monterrey office needs the same role as the one in San Salvador, who approves a change to the role, and what to do about the eleven clerks who hold vendor-master edit rights nobody can explain. Then the ERP is upgraded, two entitlements are renamed, a new reporting tool arrives, and the questions start again. That continuing work is role engineering.

It matters because roles carry so much of the load in the rest of this module. JML uses them as the birthright bundle a joiner receives. Access request can offer a role instead of twelve separate entitlements. Certification can review a role’s content once instead of reviewing the same forty entitlements for every one of its members. When roles are right, all of those processes get smaller. When they’re wrong, the mistake is copied to everyone who holds the role, and it’s harder to spot than before because it now hides behind a reasonable-sounding name.

Business roles and technical roles

Most organizations that get past the first few dozen roles end up with two layers, because the people who understand jobs and the people who understand systems are rarely the same people.

A technical role bundles entitlements inside a single system. “ERP: accounts payable processing” holds the exact ERP entitlements needed to enter and match invoices, and its owner is the ERP’s application owner, who knows what each of those entitlements really allows. A business role names a job and is assembled from technical roles across systems. “Accounts Payable Clerk” contains the ERP technical role, a document-archive role, a reporting role, and access to the finance team’s shared workspace. Its owner is the person who runs the function, here the head of finance operations, who knows what the job requires without needing to know the ERP’s permission model.

flowchart TD
  accTitle: A business role assembled from technical roles
  accDescr: The business role Accounts Payable Clerk, owned by the head of finance operations, is made of three technical roles. The ERP accounts payable processing role, owned by the ERP owner, holds the entitlements to enter invoices, match purchase orders, and view vendor master data. A documents role holds read access to the invoice archive, and a reporting role holds access to the payables dashboard.
  BR[Business role<br/>Accounts Payable Clerk<br/>owner: head of finance ops]
  BR --> TR1[Technical role<br/>ERP: AP processing<br/>owner: ERP owner]
  BR --> TR2[Technical role<br/>Documents: invoice archive]
  BR --> TR3[Technical role<br/>Reporting: payables dashboard]
  TR1 --> E1[Enter invoices]
  TR1 --> E2[Match purchase orders]
  TR1 --> E3[View vendor master data]
  TR2 --> E4[Read invoice archive]
  TR3 --> E5[View payables dashboard]

The split pays for itself the first time something changes. When the ERP vendor splits one entitlement into two, the ERP owner fixes the technical role and every business role that uses it is corrected at once. The payables-dashboard role can sit inside the clerk, supervisor, and controller roles without being defined three times. And each decision lands with the person who can actually make it: finance decides who is a clerk, the ERP owner decides what a clerk can do in the ERP.

Small organizations can skip the second layer for a while. With five or six core systems, a business role can point straight at entitlements and nobody gets lost. The two-layer model starts to earn its keep once there are more systems than one business owner can reason about, which tends to happen sooner than people expect.

Hierarchies, kept shallow

The RBAC standard also allows role hierarchies, where a senior role inherits everything a junior role grants and adds its own. AP Supervisor inherits AP Clerk and adds payment approval within a limit. This saves repetition and matches how people think about career steps.

It also hides access. A certifier looking at AP Supervisor sees the supervisor’s own entitlements and may not realize the role carries the whole clerk role underneath, plus whatever the clerk role inherits. Four or five levels deep, nobody can say what a role grants without a tool that flattens it. Inheritance can even assemble a separation-of-duties conflict that no one designed: the supervisor inherits “enter invoice” from the clerk, adds “approve payment,” and one person now holds both halves of a textbook conflict. Keep hierarchies to one or two levels, show reviewers the flattened content, and run conflict checks against that flattened view.

Starting from the business: top-down

Top-down role engineering begins with how the organization describes its own work. A business analyst sits with the head of a function, maps the processes the team runs, breaks each process into the jobs that perform it, and then works with application owners to list what each job needs in each system.

For a finance department, that might mean mapping procure-to-pay, record-to-report, and treasury, then naming the jobs inside them: AP clerk, AP supervisor, general ledger accountant, treasury analyst. For each job the analyst asks the same questions in every system the team touches. What does this person need to see? What do they need to change? What should they never be able to approve?

The result reads like a cross between an org chart and a process map, and that’s its strength. A certifier who sees “Treasury Analyst” knows what it is. Separation of duties can be designed in from the start, because the analyst is working from process steps and can see that creating a vendor and approving its payment belong to different jobs. And the roles describe what access is supposed to be, not what it happens to be after years of copy-and-paste.

The weaknesses are just as predictable. Interviews take weeks and depend on busy people’s calendars. Nobody remembers every system a job really uses, so the role misses the niche reporting tool, the vendor portal, the shared drive everyone relies on. And the role describes the job as its manager imagines it. Roll out a purely top-down role and you will often see half its members request the same three missing entitlements in the first week.

Starting from the data: bottom-up and role mining

Bottom-up role engineering starts from what people already hold. The program pulls every user-to-entitlement assignment from the connected systems, using the same discovery and aggregation described in the catalog article, and looks for sets of entitlements that many people have in common. The technique that does this at scale is role mining.

Picture a large grid with one row per person and one column per entitlement, with a mark wherever a person holds an entitlement. Mining algorithms look for groups of rows that share most of the same columns. Each group’s shared columns become a candidate role. The math varies by product, but the idea is that simple.

flowchart TD
  accTitle: From raw assignments to reviewed candidate roles
  accDescr: Raw assignments of entitlements to people are cleaned by removing orphaned and inactive accounts and access already governed as birthright. A clustering step groups people who share similar sets of entitlements. Each cluster is compared with HR attributes such as department and job title. Candidates that meet the quality thresholds go to a business owner, who approves, adjusts, or rejects them.
  A[Assignments<br/>person x entitlement] --> C[Clean the data<br/>orphans, inactive,<br/>birthright removed]
  C --> K[Cluster people<br/>by shared entitlements]
  K --> AT[Compare with HR attributes<br/>department, title, location]
  AT --> Q[Apply quality thresholds]
  Q --> R[Business owner reviews:<br/>approve, adjust, reject]

A few practical choices decide whether mining gives you something usable. Clean the input first: orphaned accounts, inactive people, and service accounts distort the clusters, and birthright access shows up in every cluster if you leave it in. Mine one department or one application at a time, because mining a whole company at once tends to produce either a few meaningless mega-roles or thousands of tiny ones. Set two thresholds deliberately: how many people a candidate must cover to be worth a role, and what share of a cluster’s members must hold an entitlement before it’s included. Lower thresholds give you more, smaller, tighter roles; higher thresholds give you fewer, broader roles with more exceptions.

Then use HR attributes to explain what you found. A cluster whose members share a department and a job title is probably a real job. A cluster with nothing obvious in common is either an informal team, which is worth a conversation, or the trace of someone copying their own access to every new hire.

That last case is the one to watch. Mining describes the present; it has no idea whether the present is right. If one supervisor spent years giving every new clerk vendor-master edit rights, mining will propose a clerk role that includes them, and that role will hand a separation-of-duties conflict to every future clerk automatically. This is why mined candidates always go to an owner who can tell “everyone has this” from “everyone should have this,” and why a candidate called “Cluster 47” isn’t a role until someone gives it a business name and takes responsibility for it.

Where the two approaches converge

Almost every role program that works in practice is hybrid. Top-down gives you intent and structure; bottom-up gives you evidence and coverage. The interesting part is what happens where they disagree, because each disagreement tells you something.

A sequence that works in most organizations goes like this. Start with a top-down skeleton for one area of the business: the jobs, their owners, and a rough idea of what each needs, without trying to list every entitlement yet. Then mine the same area’s real assignments and lay the clusters next to the skeleton.

Where a cluster matches a job, the cluster’s entitlements become the draft content of the role, now with a business name and an owner. Where the job predicts access the data doesn’t show, ask whether the job really needs it; sometimes the interview described work that moved to another team two years ago. Where the data shows access the job didn’t predict, someone has to decide whether it’s legitimate, in which case it goes into the role, or accumulated excess, in which case it stays out and certification removes it.

Before any draft role goes live, run it through the separation-of-duties rules, flattened through any hierarchy, because a role with a conflict inside it assigns that conflict to every member at once. Then pilot the roles with one team for a few weeks, watch the exceptions and the requests for missing access, adjust, and expand.

The reconciliation step is where most of the value comes from. Every gap between the picture the business has of its own work and the access people actually hold is either something the business didn’t know about itself or access that shouldn’t exist. Both are findings worth having, and you only get them by doing both halves.

This is also the second place the two meanings of “role” converge. The people in the room during reconciliation are exactly the cast from article 5: the analyst who ran the interviews, the application owners who know what each entitlement does, the architect who owns the structure, and compliance checking the result against policy. A role program staffed only by IAM engineers can run the mining. It can’t do the reconciliation.

It also takes longer than the mining suggests. The clustering for a function of 60 or 80 people runs in an afternoon. The interviews, the reconciliation meetings, the conflict checks, and a pilot usually take four to eight weeks for that same function, most of it waiting on business owners’ time. Planning the program around the slow part, and lining up owners’ calendars before the data work starts, avoids the common situation where a pile of mined candidates sits unreviewed for months and slowly goes stale as people change jobs.

What a good role looks like

It helps to agree on quality criteria before anyone creates roles, because without them every team’s request for “a role just for us” gets approved and the catalog starts to sprawl.

A role should cover most of what its members need. If every Claims Adjuster still requests eight entitlements individually, the role is missing something. Its members shouldn’t carry many exceptions either; an exception is access someone holds outside their roles, and while a few are normal (a project, a temporary assignment), a role whose members average ten exceptions each probably has the wrong content.

It should have enough members to be worth managing. A role with two people in it is an individual access profile with a name. Many programs set a floor of five to ten members and allow explicit exceptions for genuinely unique, high-risk jobs like a treasury signatory.

It must not contain a separation-of-duties conflict. If a job truly requires both halves of a conflict, that’s a process problem to solve with a compensating control, not something to bury inside a role definition where nobody will look at it again.

And it needs an owner and a name people can read. “Claims Adjuster, property, up to $25k authority” tells an approver and a certifier what they’re looking at. “CLM_ADJ_GRP_3” tells them nothing.

Role explosion

Role explosion is what happens when an organization ends up with more roles than it can understand, certify, or maintain. Some companies reach the point of having more roles than employees. Nobody plans it. It builds up one reasonable request at a time.

The most common cause is turning every variation of a job into its own role. A teller in each of four regions, at three seniority levels, on two shifts, becomes 24 teller roles. Another cause is creating a new role whenever someone needs a slightly different set of access, because that’s quicker than arguing about whether the existing role is right. Roles built for a reorganization or a one-off project are rarely retired, so they stay assignable and keep showing up in certification campaigns. And mining with loose thresholds produces a candidate for every small cluster in the data.

You can usually see it coming. The number of roles climbs faster than headcount, many roles have fewer than five members, pairs of roles differ by one or two entitlements, some people hold ten or more roles, and certifiers can’t explain the difference between two roles they’ve been asked to review.

The structural fix is to stop encoding variation as roles. Keep one Teller role and let attributes and policy handle the rest: the teller’s branch attribute decides which accounts they can see, and their authority level sets the transaction limit. That’s attribute-based access control working alongside roles instead of replacing them. The role says what kind of work the person does; the attributes say which specific resources and limits apply within that work. Most organizations that get role explosion under control end up with this kind of hybrid RBAC and ABAC design.

The rest is process, and it belongs to the governance forum from article 5: quality thresholds before a new role is approved, a periodic review of the role catalog, automatic flags for roles that fall below their minimum membership, and a defined way to retire roles.

Roles for people who aren’t employees

The identity data model article separated employees from contractors, vendors, and non-human identities, each with its own authoritative source. Role design has to respect that split.

A contractor doing an AP clerk’s work may need the clerk’s operational access but none of the employee-only entitlements that the catalog’s population eligibility excludes, and the contractor’s role should end with the contract. You can handle this with a narrower contractor version of the business role, or with one role whose entitlements are filtered by population when it’s assigned. The second option avoids doubling the number of roles, which matters given everything above about explosion.

Service accounts and other non-human identities rarely fit business roles at all. They don’t have jobs; they have an integration to run. Giving a service account a human business role is a common way it ends up with far more access than the integration needs. A narrowly scoped technical role per integration, owned by the application team responsible for it and reviewed in the account reviews from the certification article, works much better.

The role lifecycle and two kinds of review

Roles age the same way entitlements do, so they move through the same states the catalog article described: proposed, active, revised, deprecated, retired. What’s different is that a role needs two separate kinds of review, and programs often run only one.

The first is a review of membership: should each person in the role still be in it? For business roles assigned automatically from HR data, where everyone with job code 4410 gets AP Clerk, membership mostly follows the accuracy of the HR record and the JML process, and an item-by-item membership review adds little. For roles people request, membership review works like any other certification.

The second is a review of content: does the role still contain the right entitlements? This is the review that catches a role that quietly absorbed an extra entitlement, or one whose technical roles changed when an application was upgraded. The role owner does it, usually once a year and whenever the content changes. For roles assigned to hundreds of people it matters more than the membership review, because a role with the right members and the wrong content gives the wrong access to all of them at once.

It follows that changing a role’s content deserves the same scrutiny as granting access. Adding one entitlement to a role with 300 members is the same as granting it to 300 people. That change should be requested, justified, approved by the role owner and the entitlement owner, checked for conflicts against the rest of the role, and logged.

Back to Sara’s team

Sara’s accounts payable function has 64 people across three offices, all of them onboarded by copying someone else’s access.

The business analyst starts top-down with Sara, and they settle on three jobs. Clerks enter and match invoices. Supervisors approve payments within an authority limit and handle exceptions. A small vendor-master team creates and maintains vendor records, kept deliberately separate from the other two for separation-of-duties reasons.

The IAM engineer then mines the 64 people’s assignments in the ERP, the document system, and the reporting tool, after setting aside birthright access and three orphaned accounts. Four clear clusters come out. Three line up with Sara’s jobs. The fourth is eleven people, all in one office, holding clerk access plus vendor-master edit rights.

That fourth cluster is the audit finding, now visible in the data. It turns out a former supervisor in that office copied their own access to each new hire for years. The cluster is rejected as a role, the eleven people are moved to the clerk role, and their vendor-master rights go to the ERP owner in a targeted certification, which removes them.

The smaller disagreements are useful too. Almost every clerk holds read access to a payables aging report that nobody mentioned in the interviews; Sara confirms they rely on it daily, and it goes into the clerk role. The draft supervisor role included a bank reconciliation entitlement that almost no supervisor holds; that work moved to treasury two years earlier, so it’s dropped.

All three roles pass the conflict check, since vendor-master work sits in its own role and nothing combines it with payment approval. The offices handle different claim ledgers, which is solved with a region attribute instead of three regional copies of each role. After a month’s pilot in one office, the roles go live everywhere. Role coverage for AP goes from nothing to 87% of their access, exceptions per person drop from fourteen to two, new hires get the right access on their first day through their job code, and the audit finding closes with evidence that no AP role can grant both sides of the conflict.

A shorter example: when mining is premature

A 70-person startup asks its first IAM engineer, Daniel, to “set up roles.” He finds 70 people, 14 systems, and access granted almost entirely by hand as people asked for it.

Mining here would produce noise. There are too few people per job for stable clusters, and the company reorganizes every few months, so any role defined today will be wrong next quarter. Daniel proposes something lighter: a birthright bundle for everyone, four or five broad department roles agreed in an afternoon with each department head, and time-limited access requests for everything else. Mining goes on the roadmap for when the company passes a few hundred people and its jobs settle down.

The general point is that role engineering effort should scale with the number of people doing similar work. Where that number is small, a few broad roles plus good request and certification processes beat an elaborate role model.

Common mistakes

Turning the current state into roles without owner review is the most expensive one, because it takes accumulated excess, including existing conflicts, and spreads it to every future member automatically.

Creating a role for every variation of a job leads straight to explosion. Roles without owners drift; content grows and membership changes and nobody reviews either. Trying to design roles for the whole organization in one project produces a design that’s out of date before it’s deployed, so go one function at a time.

Exceptions are easy to ignore and full of information. If more and more people need the same exception, the role is missing something. If the exceptions are all different, the role may be the wrong shape. And reviewing membership without ever reviewing content confirms the right people are in a role without confirming the role gives them the right access.

Measuring role health

A useful single number is the ratio of roles to people. There’s no universal target, but a role catalog growing faster than headcount is almost always heading toward explosion.

Where this maps to standards

The formal basis for most of this is ANSI/INCITS 359, the RBAC standard, which defines core RBAC, role hierarchies and the static and dynamic separation-of-duty constraints that keep conflicts out of role definitions. NIST’s RBAC project collects the model’s history and its role engineering literature, including the Ferraiolo, Sandhu and Kuhn model the standard grew out of. For the hybrid designs that absorb variation without new roles, NIST SP 800-162 is the reference guide to ABAC. Auditors will usually point to NIST SP 800-53 Rev. 5, whose controls AC-2 and AC-6(7) require reviewing the privileges assigned to roles, which is the content review described above. And the IDPro Body of Knowledge treats role management and role mining as practitioner discipline, which is a good place to read how other programs have done it.

Closing the loop

This module started with access request and certification, two processes that work one entitlement at a time. Roles are what let them work at scale. They’re also the clearest place in the domain where the program’s people and the program’s access model meet: each role is a bundle in the catalog’s sense, shaped to fit a job, built and kept honest by the people article 5 named. When those three things stay aligned, JML, access request, and certification all get simpler. When they drift apart, the problems spread quietly to everyone holding the role.

Recap

Role engineering is the continuing work of deciding which roles exist, what they contain, who gets them and who owns them; RBAC is the model, and role engineering is the program that keeps it true. It’s where this domain’s two meanings of “role” meet, because each role is a bundle of entitlements meant to mirror a real job, designed and maintained by the people from article 5. Business roles name jobs and belong to the business, technical roles cover a single system and belong to its application owner, and hierarchies stay shallow so nobody loses sight of what a role really grants. Top-down design is clean but incomplete, bottom-up mining is complete but faithfully copies existing mistakes, and the value comes from reconciling the two where they disagree, which is exactly how Sara’s eleven clerks surfaced. Mining finds what’s common rather than what’s correct, so every candidate needs an owner and a conflict check before it becomes a role. And explosion is contained by keeping roles broad, handling variation with attributes, and reviewing what roles contain, not only who holds them.

Three questions to test yourself

1. Mining proposes a candidate role for 40 people that includes both “create vendor” and “approve payment.” What does that tell you about the data, and what should happen to the candidate?
2. A bank wants separate teller roles for each of its 30 branches at three seniority levels. Why is that a problem, and how would you redesign it?
3. For a business role assigned automatically from HR job codes, why does a review of the role’s content matter more than a review of its membership?

Hands-on exercise

Pick a team of at least ten people you know well, your own or an imagined operations team.

1. Define two to four jobs top-down, with a one-line description and an owner for each.
2. List what each job needs in at least three systems, grouped into technical roles per system and business roles per job.
3. Decide which kinds of variation (location, seniority, shift) you would handle with attributes instead of new roles, and how.
4. Check your roles against one separation-of-duties rule, then write down the minimum membership and maximum exceptions a new role on this team would need to meet before approval.