Managing IAM and SOX Compliance in Decentralized Organizations

For large group enterprises, Identity and Access Management (IAM) is an essential part of the wider control environment. If that environment is heavily decentralized, it makes the challenge of managing IAM considerably harder. The more individual legal entities, divisions, or brands that retain autonomy over their systems and access processes, the more complex IAM becomes.

A level of autonomy can support local accountability and allow entities to operate in ways that suit their individual needs. But if your wider group is subject to the Sarbanes-Oxley Act (SOX), you still must demonstrate that access to financially significant systems is appropriately controlled across the organization.

SOX Section 404 requires management to establish, maintain, and assess effective internal controls over financial reporting. For IAM and security leaders, this means you need to be able to demonstrate who has access to critical systems, who approved that access, whether reviews are effective, and whether identified issues are remediated with appropriate evidence.

The answer does not have to be complete IAM centralization. A federated model can preserve local execution while giving you a consistent way to set expectations, understand risk, and demonstrate control effectiveness across the group. The important question is where consistency is required and where local autonomy still adds value.

IAM value through People, Protection, and Performance 

In a federated organization, your IAM model needs to do more than satisfy a set of access controls. It needs to establish clear accountability across group and local teams, protect critical systems, and support the business as it grows and changes.

These priorities can be considered through three connected dimensions:

• People: Clear ownership and decision rights help your group and local teams understand their responsibilities and where accountability sits.

• Protection: Consistent, auditable controls help you protect critical systems and give the wider group confidence that access risk is being managed appropriately.

• Performance: Your IAM processes need to support acquisitions, divestments, onboarding, and organizational change without creating unnecessary friction.

  The challenge is achieving all three without forcing every legal entity to operate in exactly the same way.

Why federated IAM creates a SOX challenge

In many large groups, IAM has evolved over time rather than through a single centrally designed architecture. Acquisitions, independent business units, and locally driven technology decisions can leave you with different entities operating their own identity governance processes.

Some parts of your organization may operate highly automated controls, while others still rely on manual reviews and evidence gathering.

That variation is not automatically a problem. Your local teams will often understand their own applications, users, and business processes better than a central function could. However, problems can arise when these different ways of working prevent you from establishing a reliable group-level view of control.

Differences in access definitions, review practices, control ownership, and evidence standards can make it difficult to determine whether risks are being managed consistently. 

The challenge becomes greater when users or business processes cross legal-entity boundaries.

Someone may appear to have appropriate access when one entity or application is considered in isolation, but their wider access could create a segregation-of-duties conflict elsewhere. You may also find that a user retains access after changing roles because separate entities hold different identity records or use different joiner, mover, leaver (JML) processes.

Growth can also compound the problem. An acquisition can introduce another identity source, another set of access controls, and different evidence standards. A divestment creates the opposite challenge, requiring you to separate access cleanly without disrupting the businesses involved.

Your governance decision is therefore not whether everything should be centralized. It is deciding what you need to control consistently across the group and what can continue to be executed locally.

Set common control outcomes, not identical processes

You do not need every legal entity to run IAM in exactly the same way. But you do need confidence that the controls that matter are achieving a consistent outcome.

One entity might conduct an access review through an automated IGA platform, while another uses a different workflow. Both approaches may be acceptable if each can demonstrate who reviewed the access, what was reviewed, which exceptions were identified, and how those issues were resolved.

The same principle applies to segregation of duties, privileged access, JML controls, and evidence retention.

You therefore need a minimum control baseline for the areas where inconsistency would create unacceptable financial reporting or security risk. This baseline should define the required outcome, who owns it, and what evidence is needed.

Your local entities can then determine how they meet those requirements where different processes or technologies are justified.

This approach balances both extremes. If you impose one operating model everywhere, you risk removing useful local knowledge and creating resistance. If every entity defines its own standards, group-level assurance just becomes much harder.

Taking a risk-based approach also means you do not need to resolve every IAM inconsistency at once. SOX-scoped applications, privileged access, financially significant roles, and higher-risk segregation-of-duties conflicts give you a practical place to start.

Create group-level visibility without centralizing every process

Consistent control expectations are only part of the story. You also need enough visibility to understand access and risk across entity boundaries.

Your local teams may have a detailed understanding of who can access their own systems, while centrally you lack a consolidated view of access spanning multiple legal entities, shared platforms, and business processes.

This can make it difficult to identify inappropriate access to financially significant systems, users whose permissions span several entities, or segregation-of-duties conflicts that emerge across different applications. It can also make it harder for you to confirm that access has actually been removed when someone changes roles or leaves.

The National Institute of Standards and Technology (NIST) offers guidance surrounding the segregation of duties, which recognizes that violations can span systems and application domains. That is particularly relevant in a federated model because a user can appear compliant within one entity while creating additional risk when their wider access is considered.

You can improve that visibility without moving every IAM process to the center. Common reporting, evidence requirements, and control definitions can give your group functions a clearer view of where reviews are overdue. They can also enable you to pinpoint where exceptions exist and where local controls are falling outside agreed standards.

Evidence generation should also be part of your normal IAM activity, rather than an annual audit exercise. Approvals, reviews, remediation, and control-owner signoffs should create the evidence you need as the work happens. This reduces the effort required to reconstruct it later and gives you a more current view of control performance.

Define the operating model before you consolidate technology

Once you know which outcomes need to be consistent, you can then define how responsibility should be divided between the group and its legal entities.

Your group-level responsibilities will typically include policy, SOX control standards, reporting, and oversight. Local teams may retain responsibility for application-specific execution and role management.

In short, the boundaries need to be explicit. Who owns the control? Who accepts an exception? Who decides whether access is appropriate? When does an issue need to be escalated to the group? These are all important questions.

With clear decision rights, you can help prevent accountability gaps without removing local expertise where it contributes to effective operational management. Only then should you decide what your technology model needs to look like.

Consider this next step carefully. Technology consolidation may reduce cost or complexity where several platforms duplicate functionality. But if you centralize technology before agreeing how IAM should operate, you can simply move an unresolved governance problem onto a common platform.

Once your operating model is clear, you can make a more informed decision about whether to consolidate platforms, integrate reporting, standardize particular workflows, or retain different technologies within the same governance framework.

Build acquisitions and divestments into the model

If your organization regularly goes through acquisitions, divestments, or other structural change, IAM should be built into the wider integration and separation approach from the outset.

Without a repeatable approach, every acquisition risks becoming a new IAM discovery exercise. You need to establish which identities and applications are in scope, how access is currently controlled, who owns the relevant controls, and what evidence will be required.

A repeatable playbook gives you a consistent way to assess identity-related impacts, establish appropriate controls during transition, and coordinate access changes as entities join or leave the group.

The same applies to divestments. You need to separate access at the right point without leaving inappropriate permissions behind or disrupting the entity being separated.

Embedding IAM requirements into transaction planning reduces the amount of work you need to reinvent for each transaction and helps you maintain control confidence during significant organizational change.

Balance group assurance with local accountability

A federated IAM model does not require you to choose between group control and legal-entity autonomy. Instead, you can define the controls, evidence and decision rights that need to be consistent across the group. Local teams can then still decide how those requirements are delivered where their local knowledge matters.

That distinction is what makes the model scalable. You gain a consistent basis for SOX assurance and group-level oversight without imposing unnecessary uniformity on every part of your organization.

Technology can then support your model, rather than define it, and acquisitions or structural changes can follow an established approach, instead of starting again each time.

The objective is not to make every legal entity operate identically. It is to give you confidence that the controls that matter are understood, evidenced, and operating effectively across the group, while preserving local autonomy where it continues to deliver business value.

Unsure whether your IAM model can support SOX compliance at scale? Talk to us about assessing your current IAM operating model, identifying control gaps, and defining a practical governance approach that works across your group.