Who Actually Owns Access? A RACI Guide to Federated Identity Governance

RACI is the difference between federated identity governance as a plan and federated identity governance as something that actually runs in production. Without an explicit view of who is Responsible, Accountable, Consulted, and Informed (RACI) for the core governance activities, your program will keep stalling after the first tranche of applications.

If you are a CISO, CIO, or Identity/GRC lead in a SOX‑regulated, multi‑ERP environment, this probably sounds familiar. You have an IGA platform, SSO, and well‑documented workflows for your core ERP and HR, but material findings still show up in “secondary” SaaS, integrations, and service accounts that never made it into the central model. Finance worries about misstatement risk and slow close; Internal Audit worries about explainability and who actually owns access in all those systems.

This guide maps out ownership across the key domains of access decisions: 

• Policy definition and maintenance
• Application onboarding
• Certifications and periodic reviews
• Exception handling and break‑glass access 

It shows how to split work between central teams and federated business and application owners, and gives you minimal and mature RACI templates you can adapt inside your own federated identity governance operating model.

Why ownership is the bottleneck

IGA programs delivered real value for a narrow set of systems: automated lifecycle for core ERP and HR, structured access reviews, and audit‑ready evidence where everything is integrated. The application and identity landscape then grew exponentially with SaaS applications, local automations, and nonhuman identities that are still not represented in the central model.

As a result, central IAM and IGA teams assumed ownership of everything: connectors, policies, approvals, reviews, and exceptions. They became the approval bottleneck for new applications and integrations, and in many cases business teams ended up managing access with spreadsheets and email threads.

In many organizations, the sequence looks like this: IGA is often treated as mature once the first wave of systems is onboarded. Every additional application feels like a mini‑project because someone has to rediscover who owns access, policies, and reviews. Over time, audit findings and incidents start to cluster in SaaS applications, integrations, and service accounts that never made it into formal governance.

The core issue is that ownership is unclear, fragmented, and tends to default back to central teams. A federated RACI makes ownership explicit and reusable so you do not renegotiate it for every application, domain, and new risk.

The domains that must have clear RACI

In a federated identity governance model, these are the domains where ownership clarity matters most.

Access decisions

This is the day‑to‑day work of approving, changing, and removing access for human and nonhuman identities. When central teams approve access they do not fully understand, risk increases and throughput drops; when no one knows who approves what, tickets bounce and business units create workarounds.

In a federated model, business and application owners are Responsible and often Accountable for access decisions in their systems, operating within central policy and segregation‑of‑duties guardrails.

Policy definition and maintenance

Global identity policies, SoD rules, minimum control standards, and domain‑specific application rules need different owners. If everything stays central, the model becomes rigid and slow; if every domain invents its own policies, you lose coherence and auditability.

Central teams own global policy, risk models, and minimum standards, while domains own how those policies are applied locally—roles, groups, workflows, and rules within specific applications and processes.

Application onboarding

Onboarding is the work of discovering a system, connecting data, normalizing identities and roles, mapping to policies, and enabling monitoring. Traditional IGA treats this as a bespoke project for every application, turning IT into the bottleneck and freezing coverage after the initial wave.

In a federated model, IT runs a standardized onboarding factory pattern, while app owners are Responsible for supplying local mappings, approvers, and review patterns. This is what changes the unit economics of onboarding and enables full‑estate coverage. It is also what improves the two metrics that matter most: coverage and time‑to‑coverage.

Certifications and periodic reviews

Access reviews and other periodic certifications are where governance meets reality: who still needs what access, and who is watching high‑risk transactions and configuration changes. Centralized campaigns that hit only a few integrated systems create certification fatigue without addressing the real blind spots.

Federated governance expects app and process owners to be Responsible for reviews in their systems, within standards for frequency, scope, and evidence defined by the central team. Central teams remain Accountable for defining review policy and ensuring that coverage grows beyond the initial core of ERP and HR.

Exception handling and break‑glass

Emergency access, SoD exceptions, and one‑off rule breaks are unavoidable. Without clear ownership, exceptions become permanent, undocumented, and invisible; with over‑centralization, exceptions pile up in queues and business units respond by creating shadow practices.

In a federated model, central teams define when exceptions are allowed, how they are logged, and how they expire, while business owners are Accountable for initiating, justifying, and cleaning up exceptions in their domains.

Central vs federated owners: the split

Federated identity governance is built on a clean split between the control plane—policy, visibility, reporting—and the execution plane where applications, data, and identities actually reside.

Central teams (control plane)

Typically CISO, Identity/GRC lead, central IAM/IGA operations, and Internal Audit.

They are Accountable for:

• Control‑plane design: Shared policies, risk models, minimum standards, and evidence requirements.
• Guardrails: Global SoD rules, logging and approval standards, exception patterns and inheritance.
• Coverage and time‑to‑coverage metrics across applications and identities.
• Oversight and assurance with Internal Audit and regulators.

They are Responsible for:

• Authoring and maintaining global policies and SoD rules.
• Operating the onboarding factory as a shared service.
• Designing and maintaining the federated RACI framework itself.

Federated business and application owners (execution plane)

Typically application owners, process owners, HR and IT for workforce access, and platform teams.

They are Responsible for:

• Day‑to‑day access decisions and changes in their systems, including nonhuman identities.
• Local role and group design that implements global policies in application terms.
• Providing approvers and reviewers for onboarding and review campaigns.
• Initiating and managing exceptions and break‑glass access.

They are Accountable for:

• Meeting minimum control standards in their applications and processes.
• The completeness and quality of evidence in their domain.

HR, Internal Audit, and DevOps/integration teams play cross‑cutting roles as sources of events, control owners, and validators. Federated identity governance only works when all of these actors see themselves in the model and understand their part.

Minimal viable federated RACI

You do not need a perfect matrix to get started; you need a minimal, reusable RACI for one high‑risk domain that you can scale. Start with roles everyone recognizes:

• CISO / Identity Governance Lead
• Central IAM / IGA Operations
• Application Owner
• Business Process Owner
• HR
• Internal Audit

Then define ownership across the key domains:

Usage guidance:

• Start in one domain, such as finance/ERP plus key SaaS, and use this table as the working agenda for a 60–90 minute session with CISO/Identity, app owners, HR, and Internal Audit.
• Focus on aligning Responsible and Accountable; Consulted and Informed can be tuned over time.
• Embed the RACI into your onboarding checklists and review campaigns so it is part of execution, not a separate document.

Treat this as the version you can explain on a single slide to your steering committee or audit committee.

Mature federated RACI for scale

As you branch out across domains, you can introduce more granular roles—data owners, SoD/ITAC owners, platform architects, DevOps and integration owners for nonhuman identities. The structure stays the same: central teams hold the guardrails and metrics; domains own execution with clear responsibilities.

In a mature model, you might distinguish human vs nonhuman access decisions and certifications, explicitly assigning DevOps or integration platform owners as Responsible for service accounts, API keys, and bots. You might also separate data owners and SoD owners where regulatory and financial reporting risks are highest.

The key is consistency: you reuse the same RACI skeleton across finance, HR, operations, and engineering, while allowing each domain to plug in its own app, process, and data owners. That consistency is what lets you talk credibly about federated identity governance as an enterprise operating model, not just a project in one corner of IT.

What clear RACI changes

When RACI is explicit and embedded in your federated model, three things change.

First, friction with business units drops. App owners know exactly what they are signing up for, and central teams present standardized patterns instead of one‑off asks. Governance becomes a shared framework, not a central gate.

Second, onboarding speeds up and time‑to‑coverage improves. Every new app or integration follows the same pattern: connect, normalize, map, govern—with known owners for each step. You stop renegotiating “who owns what” and start measuring how quickly new risk comes under control.

Third, adoption increases where risk actually lives. Business and platform teams see that governance helps them manage their own risk and audit exposure, rather than simply imposing central workflows. Shadow governance in spreadsheets and email can move into the federated governance model without forcing a big‑bang change.

Next step: Federated Identity Ownership Canvas

If your IGA program is technically complete but still covers only a fraction of the systems and nonhuman identities your auditors care about, unclear ownership is almost certainly the bottleneck.

The Federated Identity Ownership Canvas gives you a one‑page way to map who is Responsible, Accountable, Consulted, and Informed across access decisions, policies, onboarding, reviews, and exceptions in your own domains. Most teams use it to get one domain—often finance/ERP—under a clear federated identity governance RACI, then reuse that pattern to lift coverage and reduce audit findings quarter by quarter.

You can use it to run a 60‑minute working session with your CISO, Identity/GRC lead, app owners, HR, IT, and Internal Audit and leave with a practical federated RACI to pilot in one high‑risk domain. If helpful, we offer an optional walkthrough session to guide your team through that first canvas and turn it into a repeatable operating model.