Segregation of Duties is one of the oldest principles in internal controls. The idea is simple: no single individual should control all phases of a business transaction. In practice, especially within SAP environments, maintaining proper SoD controls is anything but simple.

This article breaks down what SoD means in an SAP context, where the most common conflicts occur, and how organizations can identify and address them effectively.

What Is Segregation of Duties?

At its core, SoD is about separating responsibilities so that errors and fraud require collusion between multiple people rather than the action of one person. In financial terms, the person who creates a purchase order should not be the same person who approves it. The person who sets up a new vendor should not be the same person who processes payments to that vendor.

These separations exist to prevent two types of problems:

  1. Fraud: When one person controls an entire process end to end, they can manipulate it for personal gain without anyone else noticing.
  2. Errors: Even without malicious intent, having a second set of eyes on critical transactions catches mistakes before they cause damage.

In regulated industries and publicly traded companies, SoD controls are not optional. Auditors expect them. Regulations like SOX (Sarbanes-Oxley), and frameworks like COSO, require them. Failing to maintain adequate SoD controls can result in audit findings, regulatory penalties, and reputational damage.

SoD in SAP: Why It Gets Complicated

SAP's authorization model is powerful but complex. Access is controlled through a hierarchy of roles, profiles, authorization objects, and field values. A single role can grant access to dozens of transactions, each of which maps to multiple authorization objects. Understanding exactly what a user can do requires analyzing this entire chain.

This complexity creates several challenges for SoD management:

Role design drives SoD risk. If roles are designed too broadly, they will inherently create SoD conflicts. A role called "Finance Super User" that includes both accounts payable and accounts receivable transactions is a guaranteed SoD problem. Many organizations inherited role designs from their initial SAP implementation and never revisited them.

Accumulation of access over time. Employees change positions, take on new responsibilities, or cover for colleagues. Each change typically adds new roles, but old ones are rarely removed. After a few years, a user's access profile may bear little resemblance to their actual job function.

Composite and derived roles add opacity. SAP allows roles to be nested and derived, which is useful for managing large authorization landscapes but makes it harder to see the full picture of what access a user actually has.

Custom transactions and authorization objects. Organizations that develop custom ABAP programs often create custom transactions and authorization objects. These need to be included in SoD analysis, but standard rulesets may not cover them.

Common SoD Conflicts in SAP

While every organization has its own risk profile, certain SoD conflicts appear repeatedly across SAP environments. Here are some of the most frequently encountered ones:

Finance (FI)

  • Vendor master data maintenance + Payment processing: A user who can create or modify vendor records and also execute payment runs can set up fictitious vendors and pay them.
  • General ledger posting + GL account master maintenance: Being able to both post journal entries and modify the chart of accounts opens the door to hiding fraudulent transactions.
  • Customer master data maintenance + Credit memo processing: This combination allows someone to create favorable credit terms or issue unauthorized credit memos.

Materials Management (MM)

  • Purchase requisition creation + Purchase order approval: Bypasses the intended approval workflow for procurement.
  • Goods receipt posting + Invoice verification: A user who can confirm receipt of goods and approve the corresponding invoice can process payments for goods never received.
  • Vendor master maintenance + Purchase order creation: Allows setting up vendors and immediately placing orders with them.

Human Capital Management (HCM)

  • Employee master data maintenance + Payroll execution: This combination allows someone to modify salary data and then run payroll, creating obvious fraud risk.
  • Time management + Payroll processing: Similar risk around manipulating hours and processing the resulting payments.

Basis / System Administration

  • User administration + Role administration: A user who can both create users and assign roles to them can grant themselves or others unrestricted access.
  • Transport management + Development access: Being able to both develop code and move it to production bypasses change management controls.

How to Identify SoD Conflicts

Identifying SoD conflicts requires two things: a ruleset that defines which combinations of access are considered risky, and a tool that can analyze user access against that ruleset.

Building or Obtaining a Ruleset

A ruleset is essentially a matrix that maps out which pairs (or groups) of functions are incompatible. Each function is defined by the transactions and authorization objects required to perform it. Building a comprehensive ruleset is a significant effort that requires both SAP technical knowledge and business process understanding.

Some organizations build their own rulesets from scratch. Others start with standard rulesets provided by tool vendors and customize them for their environment. The key is that the ruleset reflects your actual business processes and risk appetite, not just a generic template.

Analysis Tools

Several tools can perform SoD analysis against SAP environments:

SAP GRC Access Control is SAP's own governance, risk, and compliance suite. It provides access risk analysis, emergency access management (firefighter), and access request workflows. It is a mature product with deep SAP integration, but it requires its own SAP system to run, which means licensing costs, infrastructure, and ongoing maintenance.

MTC Skopos takes a different approach. It is a portable application that performs SoD and critical access analysis without requiring installation or a dedicated server. It can work offline, supports cross-system analysis (including non-SAP systems), and includes simulation capabilities for testing role assignments before they go live. For organizations that need fast, flexible SoD analysis without the overhead of a full GRC deployment, this is a practical alternative.

Spreadsheet-based analysis is still common, particularly in smaller organizations. While functional for basic checks, it does not scale well and is prone to errors. As your SAP environment grows, manual analysis becomes unsustainable.

Remediating SoD Conflicts

Finding conflicts is only half the battle. Remediation is where the real work happens.

Remove Unnecessary Access

The first step is always the simplest: remove access that users do not need. A thorough user access review, comparing assigned roles against actual job functions, will typically eliminate a significant portion of SoD conflicts.

Redesign Roles

If your roles are too broad, no amount of access removal will eliminate SoD conflicts. Role redesign involves breaking down overly permissive roles into smaller, more focused roles that align with specific job functions. This is a larger effort but pays long-term dividends.

Apply Mitigating Controls

Some SoD conflicts cannot be fully eliminated for practical reasons. A small finance team may not have enough staff to completely separate all functions. In these cases, mitigating controls provide an alternative. These are compensating measures, such as regular review reports, approval workflows, or transaction monitoring, that reduce the risk associated with the conflict.

The important thing is to document these mitigating controls and ensure they are actually executed on a regular basis. A mitigating control that exists only on paper provides no real protection.

Prevent New Conflicts

Remediation is wasted effort if new conflicts are introduced every time access is provisioned. Implement preventive controls in your access request process. This means running SoD simulation checks before granting new roles to users, so conflicts are caught and addressed before they enter the system.

Moving Forward

SoD management in SAP is not a one-time cleanup project. It is an ongoing discipline that requires the right combination of processes, tools, and expertise. Start by understanding your current risk exposure, prioritize remediation based on business impact, and put controls in place to prevent regression.

If you need a fast, practical way to assess your SoD risk landscape, explore MTC Skopos, our risk analysis tool designed to make SoD analysis straightforward and accessible.