Rule sets

An access risk analysis is only as good as its rule set: the catalog of risks the organization cares about, expressed in terms a system can check. SAP Access Control, SAP's on-premise access governance product, ships standard rule sets for SAP S/4HANA, SAP ERP and SAP CRM, and also for some non-SAP applications. Contoso runs Access Control 12.0, whose mainstream maintenance ends at the end of 2027 (extended maintenance to 2030 is optional); its successor release, SAP GRC for SAP HANA (also called GRC 2026), was released to customers in restricted shipment on 6 March 2026 and became generally available on 31 July 2026, and SAP describes it as an upgrade path for licensed customers rather than a new product. SAP Cloud Identity Access Governance (IAG) is SAP's cloud service for the same kind of analysis on cloud applications; SAP positions it as complementary to Access Control rather than a replacement, and the IAG Bridge lets the two share risk content, mitigation and role simulation. Check the Product Availability Matrix for the current status of each before you plan a move. Delivered rules are a starting point: implementation means evaluating them and tailoring them to your processes.

Four building blocks

RiskThe thing that could go wrong, with a risk type (SoD, critical action or critical permission), a business process, a risk level and an owner. Example: create a fictitious supplier and pay it.

FunctionsThe business tasks that make up the risk. An SoD risk combines two or more; a critical action risk has one. Example: maintain supplier master; process supplier payments.

ActionsThe ways to perform a function in the system: transactions, Fiori apps and their services, RFC function modules. Example: BP, Manage Business Partner Master Data.

PermissionsThe authorization objects and field values that make an action effective. Example: change activity on the supplier master objects.

How a rule set breaks a risk down until a system can test it.

The Sign-Off Table · thesignofftable.com/academy/sap-sec-204

SAP's training describes the function catalog as grouping the actions and permissions needed for a business function, such as processing vendor invoices. Risks are organized by business process and classified as single-system or cross-system; a cross-system risk might combine supplier maintenance in one system with payment in another.

Why permissions matter

A rule that checks only actions ("can the user start transaction BP?") reports many false positives, because many users can start a transaction in display mode. Checking permissions too ("and do they have the change activity on the supplier objects?") narrows the result to users who can actually perform the function. Most organizations analyze at permission level for that reason. The price is maintenance: when SAP adds a new app that maintains suppliers, someone has to add it as an action to the right function, with the right permissions, or the rule set goes blind to it.

Action-level rules flag anyone who can start BP; adding the permission check keeps only users who can actually change suppliers.

The Sign-Off Table · thesignofftable.com/academy/sap-sec-204

Element	Contoso example	Who maintains it
Risk	P001: maintain fictitious supplier and process payment (SoD, high)	Risk owner (Dan for finance), with Nadia
Function 1	Maintain supplier master data	Nadia's GRC team, validated by the master data lead
Function 2	Process supplier payments	Nadia's GRC team, validated by treasury
Actions	Transaction BP, the business partner Fiori apps, the payment run apps and transactions	GRC team, updated for every release
Permissions	Change activity on supplier master objects; payment run execution objects	GRC team, using SU24 data and traces

One risk at Contoso, broken down. The risk ID shown is Contoso's own example numbering.

Tailoring the rule set for S/4HANA

Replace retired ECC transactions with their S/4HANA equivalents; supplier and customer maintenance moved to the business partner.
Add Fiori apps as actions, because users in S/4HANA reach many functions without any SAP GUI transaction.
Remove risks that do not apply (for example, modules Contoso does not use) so reports are not cluttered.
Add custom transactions and apps, such as Contoso's core return agreement maintenance, to the right functions.
Agree risk levels and owners with the process owners, not just the security team.

Tailoring one function for S/4HANA: retired ECC supplier transactions give way to the business partner and the Fiori app that maintains suppliers.

The Sign-Off Table · thesignofftable.com/academy/sap-sec-204

ExploreLoad SAP's standard rulesReview with process owners which risks apply to Contoso.
Realize, earlyTailor for S/4HANABusiness partner, Fiori apps, custom transactions, risk levels.
Realize, midValidate the rulesTest that known conflicting test roles are reported and clean ones are not.
Every releaseMaintainAdd new apps and changed objects; retire obsolete actions.

The rule set has its own lifecycle on the program, starting well before role build.

The Sign-Off Table · thesignofftable.com/academy/sap-sec-204

What would you do?

Nadia's team loads SAP's standard S/4HANA rule set and runs a first analysis of Contoso's new roles. Dan is surprised to see almost no conflicts in procurement, although the new buyer role includes several Fiori apps for purchase orders and goods receipts. What should Nadia check first?

Key points

Rule sets express risks as functions, actions and permissions.
Risk types are SoD, critical action and critical permission; risks belong to a process and have a level and owner.
Permission-level analysis removes false positives from display-only access.
Tailor SAP's standard rules for S/4HANA: business partner, Fiori apps, custom transactions.
Validate the rule set with known conflicting and clean test roles.

Four building blocks

Why permissions matter

Tailoring the rule set for S/4HANA

Lesson check