Introduction – can the SoD matrix from SAP ECC be simply copy&paste to S/4HANA?

Migrating authorizations from SAP ECC to SAP S/4HANA is not just a technical upgrade — it’s a moment when many organizations, often for the first time in recent years, take a holistic look at their access design. S/4HANA introduces a wide range of new business functionalities, which significantly impact the existing Segregation of Duties (SoD) matrix originally built for ECC.

Business layer

The way business processes operate in S/4HANA has changed significantly – new flexible approval workflows have been introduced (for purchase requisitions, purchase orders, and invoices), along with the centralized Business Partner model, extended budget control mechanisms, automated accounting based on the Universal Journal, and new cloud and cross-module integrations (FI–MM–CO–SD). Users now have broader decision-making and configuration capabilities directly within Fiori applications: such as managing approval rules, reassigning cost center (MPK) ownership, or creating ad-hoc reports using Embedded Analytics. All of this means that the business layer of the SoD matrix must be updated: some SAP ECC risks have lost relevance, while new S/4HANA ones have emerged, resulting from greater process flexibility.

Technical layer

There is also a technical layer of change, it focus on how SoD matrix business activities are technically defined (transactions, Fiori applications, OData services and authorization objects) in the SoD matrix. The way users interact with the system has evolved: instead of executing transactions in SAP GUI, they now operate through the Fiori Launchpad (tiles/intents), while access to data and operations is handled via OData services (controlled by objects such as S_SERVICE), Spaces/Pages, Launchpad catalogs, and classical backend authorization objects. Access that once relied on a single T-code is now the result of multiple layers working together (frontend: Fiori & OData and backend: tcodes and authorization objects). This means that an SoD risk can now materialize not just at the transaction level but also within an app or service — and therefore must be defined that way in the segregation of duties matrix. This new authorization architecture contribute to the fact that the traditional approach to SAP ECC access control is no longer sufficient.

The SoD matrix

At the center of every access redesign lies something many organizations tend to overlook — the Segregation of Duties (SoD) matrix. It defines access risks and identifies potential threats arising from excessive or conflicting authorizations. It establishes the level of risk for typical business scenarios in which users operate within the S/4HANA system. For example, the matrix describes risks that occur when a user can change a supplier’s bank account and subsequently post a fictitious liability in an invoice document, or when they can receive goods into inventory that never physically arrived — thereby triggering a payment process for non-existent items. In other words, the SoD matrix defines which activities in the system can be performed together and which must remain separated to protect business processes and data from errors or fraud.

In short, the SoD matrix is a structured set of risks and sensitive activities that should be analyzed, monitored, and incorporated into access management processes to ensure the security and integrity of both business operations and the underlying data.

It’s also a key focus area for financial auditors, since one of the fundamental control mechanisms for preventing misuse is a properly designed authorization model. Yet many organizations make the same common mistake: they build roles based on the principle of “who needs what,” only later asking whether that person should have such access in the first place.

GRC Hack #1: Don’t design or build roles without SoD matrix

Before you start designing authorizations, perform a business process risk analysis and use it to create your SoD matrix as this will serve as the foundation for all role design activities.
Anyone doing it the other way around makes a conceptual error that will eventually surface during an audit. Including a dedicated authorization workstream and engaging experts who understand business process risks is a crucial, yet often overlooked as a part of any S/4HANA implementation project. Remember, the SoD matrix is a conceptual deliverable is a single document that consolidates all key principles related to security, segregation of duties, and access management.

With the transition to S/4HANA, this map must be redrawn from scratch: names, logic, and process execution methods have all changed and with them, the sources of access risk.

How to Redesign the SoD Matrix in S/4HANA

Changes to the SoD matrix in S/4HANA occur across two dimensions: the business dimension and the technical dimension. The technical dimension is usually more challenging as it requires significantly more work, and without adapting it properly, SoD analysis and reports will produce completely inaccurate results. Let’s start with the technical perspective.

Technical Dimension

In the SAP ECC system, authorizations were primarily based on transaction codes (T-codes) and corresponding authorization objects. SoD analysis therefore focused on verifying whether a user or role combined, within their authorizations, two conflicting transactions (together with the necessary authorization objects) that should not be executed by the same person in a given business process that could generate access risk for the organization. In SAP S/4HANA, this logic still applies, but the way users interact with the system has changed fundamentally. This shift has a major impact on how the SoD matrix must be defined and structured for S/4HANA.

From Transactions to Fiori Applications

Users no longer enter transaction codes in SAP GUI. Instead, they work within the Fiori Launchpad, where they access applications assigned to their roles. Each application is linked to an Intent, as a combination of a semantic object and an action, which in turn calls a specific OData service in the backend. Data is exchanged via HTTP in JSON (Odata v2, XML, V4) format and is subject to additional authorization checks. This means that user access now depends on the interaction of several components:

• the Fiori application,
• an active OData service,
• the assigned Launchpad catalog and Space/Page (despite missing page app can be available), and
• the backend authorization objects.

Missing any of these elements results in an access error, typically a 403 Forbidden or No data found message. From an SoD perspective, this means that access risks can now arise not only at the transaction level, but also at the level of Fiori applications and OData services and therefore must be represented accordingly in the SoD matrix.

GRC Hack #2: Expand the Matrix to Include Fiori Applications

If you don’t add Fiori applications to your SoD matrix, your analysis will be incomplete as reports may both miss real user access risks as well as generate false positives. It’s important to understand that Fiori applications in S/4HANA are not all the same. They fall into two main categories:

• New Fiori applications (transactional, analytical, or factsheet apps) – completely rewritten using SAPUI5 technology, communicating with the backend via OData services.
  These are the ones that most often introduce new functions and risks, e.g.: Manage Purchase Orders (F0842A), Post General Journal Entries (F0718), or Manage Supplier Invoices (F0859).
• Classic Fiori applications (GUI transactions in Fiori) – a modern UI wrapper for traditional SAP GUI transactions. In practice, these launch traditional T-codes (e.g. ME21N, FB60, VA01) directly from a Fiori tile. They still rely on classic authorization objects, but are accessed through the Fiori Launchpad.

Each application requires its own technical mapping sometimes identifying the relevant OData service and S_SERVICE authorization object and sometimes mapping it back to a traditional GUI transaction. In both cases, the same backend authorization objects from SAP ECC still apply, as they ultimately determine whether the user can perform a given operation in backend system.

Every Fiori app in S/4HANA is linked to an intent, a combination of two elements:

• Semantic Object – describes what the action relates to (e.g. PurchaseOrder, SupplierInvoice, SalesOrder).
• Action – describes what the user does (e.g. manage, create, display).

The full list of Fiori applications, including their corresponding OData services, backend objects, and system versions, can be found in the SAP Fiori Apps Reference Library – an essential source for anyone updating their SoD matrix for S/4HANA. https://fioriappslibrary.hana.ondemand.com/

This library contains hundreds in practice, thousands Fiori apps for S/4HANA.

• Many standard SoD matrices provided by SAP or vendors include only about 200 Fiori applications, which is just a fraction of the real scope.
• Conclusion: every Fiori app can represent a potential SoD risk so verifying and expanding the matrix is essential.

Fiori applications and OData services

In the S/4HANA model, access to business data and processes occurs on the frontend via dedicated OData services (Open Data Protocol) the integration layer through which Fiori applications communicate with the SAP backend, retrieving and writing data in real time. An OData service definition is registered in the S/4HANA system on the Frontend Gateway and includes, for example:

• the technical service name (e.g. MM_PUR_PO_MAINT_V2_SRV),
• the URL path (e.g. /sap/opu/odata/sap/MM_PUR_PO_MAINT_V2_SRV/),
• mapping to a backend ABAP component,
• authorization control via the S_SERVICE object.

Example mappings:

• Manage Purchase Orders (V2) (F0842A) MM_PUR_PO_MAINT_V2_SRV – Purchasing (MM)
• Create Supplier Invoice (F0859) MM_SUPPLIER_INVOICE_MANAGE – Accounts Payable
• Post General Journal Entries (F0718) FAC_FINANCIALS_POSTING_SRV – General Ledger (FI)
• Manage Bank Statements (F1564) FAR_MANAGE_BS_SRV – Banking (FI)
• Manage Sales Orders (F1873) SD_F1873_SO_WL_SRV – Sales Orders (SD)

Each of these OData services must be activated in transaction /IWFND/MAINT_SERVICE and granted to users via S_SERVICE authorization before the Fiori app can read or write data to the backend. This is a major shift, because OData access is not tied to T-codes. It requires dedicated S_SERVICE authorization, and such access may not appear in classical role-based analyses based solely on transaction codes. Therefore, the SoD matrix must explicitly include OData services, Fiori applications, and related backend objects.

GRC Hack #3: Include OData and Fiori in the SoD matrix

A user might have access to the classic GUI transaction MIRO (invoice posting) with the required authorization objects, but lack access to the Fiori app “Create Incoming Invoice”, which uses the MM_SUPPLIER_INVOICE_MANAGE service to post invoices in the backend via Fiori. In a traditional SoD analysis, this would be reported as a potential risk, because the GRC system detects authorization for invoice posting. However, in organizations that operate exclusively through the Fiori interface and no longer use SAP GUI, the user would not be able to perform the transaction via browser access, even though the authorizations technically exist. This is a classic false positive, where a GRC system reports a risk that is not executable in practice. Such cases illustrate why SoD analysis must combine authorization logic with an understanding of how users actually work within the modern Fiori interface. Otherwise, SoD reports can become overloaded with irrelevant alerts leading to business and risks owners frustration.

GRC Hack #4: Don’t forget about OData service

OData services form a new access layer for business processes their authorization operates independently from classic transaction-level checks in the backend. If you fail to include them in your SoD matrix, a user may have real operational access to perform actions that your GRC system will never flag as risky. In S/4HANA, a typical role can include:

• classic SAP GUI transactions,
• Fiori applications,
• OData services, and authorization objects.

As a result, the SoD matrix must now evaluate whether a role combines functions that should remain segregated in the new model. It is equally important to include custom transactions and customer-specific extensions as the standard out of the box vendor SAP matrix does not cover them.

GRC Hack #6: Technical definition must include custom extensions
Don’t rely on the standard transaction list. Add to your matrix:

• all custom Fiori applications used in your organization,
• the OData services those applications call,
• and every custom app, T-code, or service built for your specific system.

Only then will your SoD matrix will better reflect the real S/4HANA environment.

 Business Dimension

If your organization has implemented custom Fiori apps, OData services, or modified backend logic, they must be manually added to the SoD matrix definition. The out-of-the-box matrix won’t be good enough and in these areas, you’ll have blind spots. With the transition to SAP S/4HANA, not only the technical structure of roles and authorizations changes, but also the very way business processes are executed in the system. This means the SoD matrix must now include new risks that simply did not exist in the old ECC world. One of the best examples involves approval workflows for purchase requisitions, purchase orders, and supplier invoices processes that, in S/4HANA, are configured through new Fiori applications such as Manage Workflow for Purchase Requisition and Manage Purchase Order Workflows. Each of these applications allows users to define approval paths (approvers), under what financial thresholds, and in which order. They can modify conditions that trigger the workflow or even rearrange the approval hierarchy. This is a powerful automation feature, but also a new source of risk for critical access (restricted access) and Segregation of duties (SoD) violations. If a user simultaneously has access to workflow configuration, purchase order processing, and the ability to edit cost center (MPK) or WBS master data, they could, for example:

• remove a budget approval step in WF config and trigger the procurement process,
• change the approver (e.g., assign themselves as owner) in cost center or WBS master data,
• modify approval thresholds or limit values effectively bypassing budget control and the SoD principle.

GRC Hack #7: Analyze new functionality for new SoD risks

Add a new activity to your SoD matrix: “Manage Workflow Configuration” (for requisitions, purchase orders, and invoices). While these authorizations do not directly post accounting entries, they can indirectly bypass procurement access controls mechanisms. User can change the procurement design approval logic. Monitor who has access to Fiori apps like Manage Workflows for Centrally Managed Purchase Requisitions and related backend services such as SWF_FLEX_DEF_SRV, which handle the workflow logic. It’s also important to add new SoD conflicts to the matrix. A good example is when a user can modify Cost Center (MPK) or WBS element master data, assigning ownership to themselves and then approve a purchase requisition for that same object. This is a real risk in S/4HANA that did not exist in ECC, because the approval of requisitions and purchase orders was previously controlled by dedicated authorization objects and the Release strategy mechanism.

In ECC, approval control for purchase requisitions (PR) and purchase orders (PO) was handled by the classic Release Strategy model, based on authorization objects such as M_EINK_FRG.
Fields of this object included FRGGR (release group) and FRGCO (release code), which determined who could approve which purchasing documents and at what level. Authorizations were tightly linked to document type, purchasing group, and release level the entire process was static and fully embedded within the transactional system.

As a result, SoD control was relatively simple: it was enough to ensure that a user could not both create and approve a requisition or order under the same release group. Everything was based on authorization objects and could be easily represented in the SoD matrix or analyzed by GRC tools.

In S/4HANA, this model has been simplified, but new business risks have emerged.
Approval processes are now driven not by static authorization objects but by flexible workflows, MPK/WBS ownership assignments, and configuration rules that can be changed from within Fiori apps.

New business SoD risk example in S/4HANA

A user has authorization to change Cost Center (MPK) or WBS master data (e.g., assign a cost owner) and the ability to approve a purchase requisition for that same object. As a result, the same person can give themselves control over a cost center or project and then approve related purchases, violating the Segregation of Duties principle, bypassing budget control, and creating the potential for fraud or misstatement.

New SoD risks aspects in S/4HANA

• Business risks – new processes and functions (e.g., approval workflows, business partners, flexible budgets) reshape SoD exposure.
• Configuration risks – users can modify workflow parameters, approval rules, thresholds, or budget role assignments.
• Automation risks – result from background workflows or schedulers performing actions without human confirmation.
• Integration risks – arise from API and OData-based integrations that link processes across modules (e.g., FI ↔ MM ↔ CO).

In the classic ECC environment, there was no concept of a user “programming” approval logic that could violate internal control policies. In S/4HANA,  thanks to Fiori  this is now a real, browser-based possibility. Therefore, the modern SoD matrix must include not only traditional actions such as Post, Change, and Approve, but also Manage Workflow, Configure Approval Process, and Change Budget Control Settings because today, risks often occur where the process is configured, not just where it is executed.

GRC Hack #8: New risks are where you configure the process not just where you execute it

In the S/4HANA environment, the line between a business user and a process configurator is becoming increasingly blurred. A person with authorization to manage workflows can, in practice, change how documents are approved — even if they formally lack posting rights. Including such roles in the SoD matrix is now a mandatory step for any organization that wants to maintain control over its procurement and approval processes in S/4HANA.

 Tools Supporting the SoD Matrix and Access Verification Process

Building an SoD matrix is only half of the success. The other half is ensuring that its content is taking into account when access management process are executed. Another aspect is that it is regularly updated, and monitored as part of daily user to role provisioning and access review processes.
This is where GRC-class tools come in — not only analyzing the SoD matrix and conflicts, but also storing knowledge about risks, linking them with business processes, and supporting audit readiness and compliance reporting.

SAP GRC Access Control 12.0 and the upcoming SAP GRC 2026

This is SAP’s flagship access governance solution and in 2026 it will be succeeded by SAP GRC 2026. It enables centralized role management, SoD conflict analysis, automated risk prevention, and end-to-end control over access request and removal workflows. With its Risk Library repository, GRC Access Control allows you to link business processes with transactions and authorization objects, including Fiori applications and OData services in newer releases. It’s an enterprise-grade solution, ideal for large organizations with complex system landscapes, multiple SAP environments, and strong audit requirements.

GRC Hack #8: If your organization plans to upgrade, ensure you migrate your risk repository and all custom extensions to the new version.

SAP IAG (Identity Access Governance)

SAP IAG is the cloud evolution of GRC that delivers the same SoD analysis capabilities, enhanced with identity management and cloud integration (e.g. SuccessFactors, Ariba, Concur). It supports real-time access analysis, automatic role recommendations (auto-proposals), and browser-based Access Request Workflow handling. In hybrid S/4HANA migration projects, IAG is increasingly becoming the central platform for access risk management.

smartGRC – a lightweight alternative and practical complement

smartGRC was designed to meet the need for simpler and more flexible access risk management. It provides a unified place to maintain the SoD matrix, analyze conflicts, manage periodic access reviews, and integrate directly with business processes. Unlike classical GRC, smartGRC can operate as both a complement to SAP tools or a standalone audit platform, particularly valuable for mid-sized organizations and multi- SAP and non- SAP centric system environments. The tool allows easy extension of the SoD matrix with custom Fiori apps, OData services, and non-SAP business applications — extracting authorization data and storing it in a universal XML format, making it possible to audit systems outside the SAP ecosystem. It is equipped with updated segregation of duties matrix risks functions definitions for the newest S/4 Hana system release. smartGRC supports import/export of the SoD matrix (CSV/XML) for non-SAP system, enabling easy synchronization with ITSM or JIRA supporting system.

Why these tools matter

While SAP GRC and IAG provide enterprise-grade control, smartGRC’s advantage lies in speed, adaptability, and cross-system risk analysis making it ideal where agility matters more than standardization. Tools enable organizations to:

• store the SoD matrix in a centralized, structured repository linking processes, transactions, apps, and services,
• perform preventive SoD risk analysis during role provisioning (“what-if” simulation before access approval),
• conduct periodic or ad-hoc SoD access reviews in production systems,
• integrate SoD analysis with change and approval workflows,
• generate audit-ready compliance reports.

From my project experience, the standard SAP SoD matrix for S/4 Hana is only a starting point as it usually includes around 200 Fiori apps, while best in class, process-driven Sod matrices contain up to twice as many. That’s why it’s essential to extend and update your matrix regularly with custom and standard Fiori apps, OData services, and project-specific enhancements.

GRC Hack #9: Treat SoD matrix like a living system

An SoD matrix that isn’t updated after every system change quickly loses its control value. Establish a cyclical review process, ideally aligned with your development and change management process cycle, to ensure that every new app, workflow, or extension is captured, analyzed and included if needed in SoD matrix.

Summary

In the S/4HANA world, a current and well-defined SoD matrix is the foundation of security, compliance, and access management process efficiency. It’s not a static document, rather it’s a dynamic control mechanism that must evolve together with the system and the organization.

Recommendations for Authorization, GRC, and Security Teams

• Refresh your SoD matrix before migrating to S/4HANA, don’t simply copy the old ECC version; many transactions are obsolete, and key functions have moved to Fiori and OData.
• Cover all authorization layers as Fiori apps, OData services, roles, authorization objects, and master data (e.g. MPK/WBS ownership).
• Retain classic authorization objects since objects like M_RECH_WRK still play a vital control role and must remain part of the SoD model.
• Integrate your GRC/IAG/smartGRC tool into the access request process as automated SoD analysis at request time prevents risk before it happens.
• Implement a recurring verification cycle: Matrix → Roles → Users → Access → Audit Report the best practice and audit requirement.
• Document every update and every role, app, or workflow change must be reflected in the matrix. The standard SAP list is now just a small fraction of your real risk landscape in S/4HANA.

Closing Thought

Your SoD matrix can become your strongest asset in the security and authorization area migration to S/4HANA, if it’s designed well, your business processes will run smoothly, risks will remain under control, and auditors will stay calm. Properly managed authorizations stop being a source of problems, they become a protective mechanism that safeguards both data and business integrity.

Filip Nowak, Partner @ GRC Advisory