Roles in an IGA Program: Who Does What

A different meaning of “role”

The last four articles used “role” in one sense only: a bundle of entitlements assigned to a population, as the entitlement catalog article defined it. This article uses the word the way everyone outside IAM does, as a person’s job. It closes the first module by naming who actually does the work the previous articles described, because none of it runs itself. Every time those articles said “governance decides,” there was a specific person behind the decision, and this article is about who that person is.

The catalog article argued that every entitlement needs a named owner and that an unowned entitlement piles up like an orphaned account. The JML article showed a mover conflict that someone had to decide on, and reviews that need someone with business context to mean anything. Both described these as structural requirements without answering a plainer question: whose job is this, in a real organization’s org chart? A policy that says entitlements need owners doesn’t create owners. A program needs people, with titles and time set aside, doing the work. This article is the roster, and the examples throughout use the same cases as the earlier articles so you can see who was behind each one.

The cast

The program manager

The program manager owns the plan, the timeline, and the coordination between teams. Not the technical design, and not any business decision about access. Their job is making sure the architect, the engineers, the analysts, and the application owners actually talk to each other on a regular rhythm, that each milestone (a discovery phase, a pilot, a first full review campaign) has an owner and a date, and that when two groups disagree, say engineering wants to move faster than a cautious application owner is comfortable with, there’s a forum to settle it instead of a standoff.

A useful discipline for a program manager is to tell a scheduling problem apart from a decision problem. A slipped deadline has scheduling fixes: re-sequence the work, add people, cut scope. A decision that’s stalled because an owner hasn’t answered is different, and it needs escalation to that owner’s own management, not a workaround that hands the decision to whoever happens to be available. A program manager who starts making entitlement decisions to keep the schedule moving is quietly undoing the governance the program exists to build.

The IAM architect

The architect designs the target state. That includes the identity data model from article 2: which systems are authoritative for what, how matching works, how often reconciliation runs. It includes the naming scheme and the risk-tier framework from the catalog article, and the patterns for connecting target systems to the platform. The architect answers for whether the design survives real edge cases: two Davids in Finance, a contractor whose engagement lapses with no termination record, a legacy system with no clean connector. A design that looks elegant on a whiteboard and falls apart at the first messy application wasn’t really designed, only sketched.

The architect is the natural author of the naming scheme and risk tiers, not because they should decide what each entitlement means, but because someone has to own the shared structure that lets hundreds of entitlements, defined by dozens of owners over months, still read as one catalog instead of dozens of incompatible local schemes.

The IAM engineer

The engineer builds and runs what the architect designed: connectors, provisioning workflows, approval routing and escalation, reconciliation jobs, and the platform configuration underneath. In a small program the engineer and the architect are often the same person, switching hats over the week. In a larger one the architect designs, the engineer builds, and the architect stays accountable for whether what’s running still matches the design once it meets real systems.

The business analyst

The analyst connects the technical team with the parts of the business the program touches. They gather the real requirements for a job’s standard bundle, interview application owners about what a permission set actually does, and translate business processes into something the architect can design against. The claims curation example in the catalog article, 340 groups reduced to five real distinctions, depended entirely on someone running structured interviews with the claims operations owner instead of guessing from group names. That interviewing is the analyst’s core contribution, and it’s easy to underestimate how much of a catalog’s quality comes from it.

A program without an analyst doesn’t skip this work. It just lands, unevenly, on whichever architect or engineer has time, which is how catalogs end up curated by people with deep technical knowledge and thin business context.

The application owner

The application owner is where most of the accountability in this module lands. They’re the owner named against every entitlement of their system in the catalog, the approver of record for requests into it, and the person a review asks to confirm that assignments are still right. They’re also the person a separation-of-duties conflict involving their system ultimately goes to: can the business tolerate this particular combination of access for this particular person? Nobody else in the cast has the business context to answer that credibly, which is why the accountability has to sit with the owner and not drift to IAM engineering just because engineering is already in the room.

The compliance and risk officer

Compliance and risk own the regulatory and control framework this domain keeps referring to: NIST SP 800-53 account management controls, the access clauses of ISO/IEC 27001, and whatever industry framework applies. Their job isn’t running reviews or defining entitlements. It’s translating what a SOX or HIPAA auditor will actually ask for into requirements the architect can design against, and checking, before an auditor does, whether the program’s evidence would hold up. That checking is worth the most when it’s routine. A compliance officer who samples a few review campaigns and reconciliation reports every quarter finds gaps while there’s time to fix them, instead of finding them under the pressure of an audit that has already started.

Security

Security’s part is narrower but sharp. It reviews separation-of-duties exceptions that carry real risk, takes part in urgent leaver events where the departure itself is a security concern, such as an involuntary termination, and brings an attacker’s view to risk tiering. That last point is worth an example. Read access to a customer database might look like a “standard” entitlement through an operations lens. To an attacker who has compromised a low-privilege account, it’s exactly what they’d want first, for reconnaissance before trying to go further. An application owner focused on daily operations doesn’t always weigh that, which is why security should review the tiering criteria themselves, not just individual exceptions.

The executive sponsor

Above the working cast there’s usually one more person, and programs that lack one tend to stall in their second year. The executive sponsor, often the CISO, the CIO, or the head of risk, owns the business case and the budget, and is the person who can tell a reluctant business unit that its application owners will make time for reviews this quarter. They don’t attend every forum meeting or approve individual decisions. Their job is to keep the program funded after the first audit pressure fades, to settle disputes between departments that the forum can’t, and to make it clear that application ownership is part of a manager’s job rather than a favor to IT.

A sponsor who only appears at kickoff is almost as bad as none. A short quarterly review with the sponsor, built on the forum’s measures, keeps them close enough to the program to defend it when budgets tighten.

People outside the IAM team who matter

A handful of groups never appear on an IGA org chart and still decide much of what the program can do.

HR owns the data most of the program runs on. Its timeliness in recording hires, moves, and terminations sets the floor for how fast joiner and leaver access can change, and the data model article explained why a conversation with HR about which fields drive access is worth more than any connector. Procurement or vendor management plays the same part for contractors, especially for end dates.

The service desk is often where IGA meets people for the first time: they answer “where’s my access,” carry out manual fulfillment for systems with no connector, and are usually the first to notice when a rule or a workflow is misbehaving. Bringing them into the program early, and giving them a way to report patterns, catches problems sooner than any dashboard.

Legal and privacy, including a data protection officer where one exists, have a say in what identity data the program may hold and for how long. Internal audit, finally, tests the same controls as the external auditors, usually earlier in the year, and is one of the most useful allies a program has.

Who’s in the room when Sara moves

The JML article followed Sara López’s promotion from customer operations analyst to fraud review team lead, and the conflict check that should evaluate her old and new access together before the new access is granted. That article described the mechanism. Here is who’s involved when it happens.

The mover event comes from HR, and the workflow the IAM engineer built evaluates it against separation-of-duties policy. The architect designed that policy, and the business analyst filled it with real business rules gathered months earlier in interviews with both the customer operations and fraud review owners. The check finds the conflict: Sara would briefly be able to flag a suspicious transaction and also clear a flag as a false positive. The system sends the decision to the fraud review application owner, the higher-risk side.

The owner doesn’t decide blind. Because of the naming work in the catalog, she can see exactly what each side grants: not two cryptic group names, but “Flag suspicious transaction” and “Override flag as false positive.” She chooses the safer path. Sara’s override access is removed first, reconciliation confirms it’s gone, and only then is the fraud review access activated, a day later than an unconditional grant would have been and with no moment when the conflict existed.

Compliance reviews the outcome afterwards, not because it had to approve it in real time, but because a documented conflict, a named decision-maker, a specific resolution, and a timestamp showing it closed within days is exactly what an auditor will eventually ask to see. The program manager never touches the decision. Their only involvement is noticing, from the workflow’s logged delays, that this kind of conflict between these two teams comes up often enough to put on the next governance forum agenda as a candidate for a standing policy rather than a one-off decision every time.

One event, five of the roles in this article, each doing a distinct part, and exactly one of them, the application owner, making the actual judgment. Most real governance events in an IGA program look like this once the roles are named.

flowchart LR
  accTitle: An access decision moves through the program roles, with the application owner deciding
  accDescr: A trigger, such as a mover event, a review finding, or a proposal for a new entitlement, is surfaced by the IAM architect or engineer, with business context from the business analyst. It goes to the application owner, who makes the decision. Compliance and risk review high-risk decisions, and the program manager tracks the outcome to closure, but the judgment itself belongs to the application owner.
  TRIG([Trigger: mover, review finding,<br/>or new entitlement]) --> ARCH[Architect or engineer<br/>surfaces it, adds context]
  BA[Business analyst<br/>business process context] --> OWNER
  ARCH --> OWNER{Application owner<br/>decides}
  OWNER -->|High risk| RISK[Compliance and risk<br/>review]
  OWNER -->|Standard| CLOSE
  RISK --> CLOSE([Program manager<br/>tracks to closure])

Who does what, event by event

The clearest way to see the roles interact is against the events the previous articles described.

The pattern in the bold cells is the point. It’s the application owner, not IAM engineering and not the program manager, who makes the substantive calls this module has been describing since the first article. Everyone else facilitates, builds, documents, or reviews. The decision about whether a specific access should exist belongs to the person with business context, every time.

Which roles to fill first

Few programs get to staff every role on day one, and the question of who comes first arises in nearly every new IGA effort.

The architect usually comes first, because almost every other role needs something the architect produces: the analyst needs a data model to gather requirements against, owners need a naming and tiering scheme before ownership means anything concrete, and the engineer needs a design before there’s anything to build. A program that hires engineering capacity before architecture tends to produce the kind of uncoordinated build the catalog article’s SaaS example described: technically working, structurally incoherent.

Engagement with application owners needs to start almost as early, before there’s even a platform to show them. The slowest part of most programs is getting business owners to invest the time that curation and reviews require, and building that relationship takes months, far longer than any technical component. Programs that treat owner engagement as a late rollout task discover, at exactly the moment they need them most, that the owners aren’t available, aren’t convinced, or don’t understand what’s being asked.

The program manager and compliance can reasonably join a little later without blocking early progress. A program manager matters once there’s enough cross-team coordination to need scheduling, and compliance’s heaviest involvement comes around control design and evidence review, which matters most once something is running. The analyst and engineer roles grow with the architect’s design: useful early, essential once there’s a design to gather requirements against and to build.

How the roles shift as the program matures

The balance between these roles isn’t fixed. It moves as the program moves from building to running.

In the first year the weight sits with the architect and the engineers: the data model, the first connectors, the leaver process, the first review of a critical system. Application owners are involved, but mostly in curating their entitlements for the first time, which is the most demanding thing they’ll be asked to do.

In the second year the weight shifts toward owners and the analyst. More applications come on board in waves, each with its own curation and its own owner to bring along, and review campaigns expand from one system to many. Compliance becomes more visible as the evidence the program produces starts to be used in real audits.

Once the program reaches a steady state, much of the build team turns into an operations team that runs connectors, reconciliation, and campaigns, and the analyst role moves toward onboarding new applications and improving existing roles. The forum becomes the center of gravity. Programs that keep a large build team long after the building is done, or that disband the forum once the platform is live, tend to lose the governance half of the loop without noticing. A yearly look at who is doing which job, compared with the roster on paper, is a cheap way to notice the drift before an audit does.

When one person wears three hats

Everything so far describes a mature program with people dedicated to each function. Most real programs, especially in their first eighteen months, don’t have that, and pretending otherwise produces a responsibility chart that looks rigorous and describes nobody’s actual week.

A common, workable small-team pattern looks like this. One person is both architect and engineer, splitting time between design and hands-on building. The program manager role is a part-time addition to someone’s existing job, often the architect’s again, or a delivery lead borrowed from elsewhere in IT. The analyst work is spread across whichever application owners have the time and interest to engage deeply, with the architect filling the gap for those who don’t. Compliance takes part on a lighter rhythm, a monthly review instead of continuous involvement, because a small compliance team covers the whole organization.

Bringing a new application owner on board

Most application owners never asked for the job. They run a business function, and one day someone tells them they now own forty entitlements in the finance system. How that conversation goes decides whether they become engaged owners or names in a spreadsheet.

A short, concrete onboarding helps more than a policy document. Explain in a page what ownership means for them in practice: approving requests for their system, a review campaign once or twice a year, decisions on the occasional conflict, and a yearly look at whether their entitlements still make sense. Give them an estimate of the time it takes, usually a few hours a quarter once the catalog is in shape, and more during the first curation. Walk them through one real request and one real review item, using their own system’s entitlements. And name a backup with them on the first day, so ownership survives their vacation and, eventually, their departure.

The first few months matter most. An owner whose first review is a list of 900 unreadable entries will conclude that ownership is a waste of time and act accordingly. An owner whose first review is thirty readable entitlements, sorted by risk, with last-use dates, usually comes away convinced it was worth doing.

The governance forum

Individually accountable roles still need a place where decisions that cut across them get made together, instead of each owner deciding alone and never comparing notes. A governance forum, a recurring meeting, usually monthly, with the architect, compliance and risk, a rotating set of application owners, and the program manager, is where that happens.

Its agenda tends to stabilize around a few standing items: the health of the entitlement catalog (ownership, overdue reviews, deprecated entitlements still assigned), open separation-of-duties exceptions and their compensating controls, gaps found by reconciliation since the last meeting, the trend in identity data quality (match, orphan, and duplicate rates), and any application whose owner is missing or unresponsive. Beyond those, it approves changes to birthright bundles, decides whether a proposed conflict rule is too strict or too loose based on how many exceptions it generates, and settles disagreements individual owners can’t, such as two owners who each think a disputed entitlement belongs to the other’s system.

This is also where the measures built up across this module actually get looked at by people with authority to act on them. A dashboard nobody reviews in a room with decision rights is just a number nobody reads; the forum is what turns measurement into governance.

The forum needs explicit decision rights, or it drifts into a status meeting where information is shared and nothing is decided. A workable pattern is that the forum can approve catalog and policy changes affecting a single application by majority, provided that application’s owner agrees, while changes to separation-of-duties policy across several applications, or to the risk-tiering criteria themselves, need compliance sign-off before taking effect. Those are exactly the changes an auditor will ask about later, and “the forum discussed it” is a weaker answer than “compliance reviewed and approved it.”

How the roster goes wrong

A few patterns recur, each a way the cast above degrades in practice even when every box on the org chart is filled.

The architect quietly becomes the application owner. Under deadline pressure, an unresponsive owner’s silence is filled by the person already in the room with system access, usually the architect or engineer, who starts deciding eligibility to keep a migration on schedule. It’s dangerous precisely because it doesn’t look like failure at the time. The migration finishes on time, and the gap only shows up months later when a review finds access nobody with business context ever approved.

The program manager starts settling policy disputes. When two owners disagree about who should own a shared entitlement or whether an exception is acceptable, the program manager, used to resolving disagreements to keep things moving, is often best placed to just decide. That’s the right instinct for a scheduling question and the wrong one for a policy question. A policy decision made that way has no compliance review and no rationale beyond “we needed to keep moving,” which is exactly what an auditor will ask about.

Compliance only appears at audit time. A compliance officer consulted only when an audit is near ends up reviewing years of accumulated decisions at once, under pressure, instead of catching control gaps as they appear. It’s the same failure as reconciling once a year, applied to compliance oversight.

Nobody owns the roster itself. Just as a catalog needs someone to keep it current, the assignment of these roles needs upkeep: an application owner changes jobs, the architect who designed the data model leaves, a new application arrives without anyone being named its owner. A program that assigned roles once at kickoff and never revisited them ends up with exactly the quiet gaps this article exists to prevent.

What happens when a role has no name

The failure isn’t dramatic. It’s the same slow drift every other article in this module described. Without a clear architect, the data model is designed piecemeal by whoever is fixing the most urgent connector that week, and the decisions about authoritative sources never get written down anywhere a newcomer could find them. Without an analyst, curation is done by engineers reading admin consoles instead of talking to the people who use the access, producing a catalog that’s technically accurate and practically unreadable for reviewers. Without engaged owners, reviews become the click-through the data model and catalog articles warned about, not because reviewers are careless but because nobody with real accountability was ever named to review. And without a governance forum, every measure this module built is collected faithfully and read by nobody.

Measuring whether the roster works

The sign that these roles are working isn’t an org chart with every box filled. It’s whether the accountability those boxes stand for is actually being exercised, and a few measures, reviewed at the forum, make that visible.

The share of applications with an actively engaged owner shows whether ownership is a real function or a name in a spreadsheet; a falling number usually means owner turnover isn’t being tracked and replaced. The average time owners take to resolve a review finding or a conflict exception shows whether decisions are timely; a rising number often means owners are under-resourced or not really committed. The share of forum agenda items that end with a recorded decision and a named owner shows whether the forum decides things or just discusses them.

The hardest measure to collect is also the most useful: how many access decisions are being made outside the named roster, informally, by engineering or the program manager. Nobody logs “I made a decision I wasn’t supposed to make.” It has to be inferred, usually by comparing who executed a change with who the responsibility chart says should have decided it. Building that comparison, even roughly, into whatever records access changes is one of the most valuable things a program can add once these roles are named, because it catches accountability gaps before a review or an audit does.

Where this maps to standards and frameworks

• The IDPro Body of Knowledge covers identity program roles and responsibilities as a topic of its own, describing much the same cast, architecture, engineering, business ownership, and governance, under similar names.
• ISACA governance guidance, including material aligned with COBIT, treats clear assignment of accountability, who decides, who is consulted, who is informed, as a basic control in its own right, independent of technology, which is the structural argument this article makes about application ownership.
• NIST SP 800-53, control PS-2 (position risk designation) and related personnel controls, require organizations to document the responsibilities of positions relevant to access decisions: the control-catalog version of having a named, accountable person behind each decision.

Closing this module

The first article opened this domain with a loop: administration carries out changes, governance decides and verifies. The articles since have built, piece by piece, what governance needs to do that for real: an identity model you can trust, a governed and auditable lifecycle, a curated catalog of what’s actually granted. This article adds the last piece, the people accountable for each half of the loop. A loop with nobody assigned to the governance half isn’t a loop. It’s administration running unchecked next to a policy document nobody reads.

The next module moves from this foundation into IGA’s core components, the machinery these five articles were preparing the ground for. None of it works without the data model, the lifecycle discipline, the catalog, or the people this module named. A platform deployed on a strong data model with a weak or unnamed roster produces the failure this module kept returning to under different names: a process that looks complete on a dashboard and isn’t, because nobody with real accountability stands behind the decisions it reports.

Recap

• This article uses “role” to mean a person’s job on the IGA program, distinct from the entitlement-bundle sense the catalog article defined. The role engineering article later brings the two senses together.
• The program manager, architect, engineer, business analyst, application owner, compliance and risk officer, and security each carry a distinct accountability. In a small program several are the same person, but the accountabilities don’t disappear.
• The application owner makes the substantive calls: what entitlements mean, who’s eligible, conflict exceptions, review decisions. Everyone else facilitates, builds, or reviews around them.
• Application ownership is the one accountability engineering shouldn’t absorb, however small the program.
• Fill the architect role first and start engaging owners almost as early. An executive sponsor keeps the program funded, and HR, procurement, the service desk, legal, and internal audit shape it from outside.
• Onboard application owners with a concrete, time-boxed explanation and a readable first review, and name a backup on day one.
• A governance forum with explicit decision rights is where this module’s measures and cross-cutting decisions get acted on together.

Three questions to test yourself

1. A small program has one person covering both the architect and analyst functions. What specific risk does this article warn about, and how would you reduce it without adding people?
2. Using the table above, explain why the application owner, and not the engineer who built the connector, decides whether a mover’s conflict is accepted with a compensating control.
3. A governance forum has met monthly for a year, but application owners have almost stopped attending. What does this article suggest is going wrong, and what would you check first?

Hands-on exercise

Think of an organization you know and an access-related decision that happened there recently, or invent one.

1. Name who played each of the roles in this article for that decision, even if one person covered several.
2. Identify who actually made the decision about whether the access should exist, and whether that matches who should have made it.
3. Write the agenda for that organization’s first governance forum, with three standing items and the decision rights for each.
4. List the two roles you would fill first if you were starting the program there tomorrow, and why.