Security-tagged controls are preventive and largely automated: they restrict, at the system level, who can touch HR and payroll data in the first place, and are tested by querying user access (transaction codes and authorization objects) against job responsibilities. Payroll-tagged controls are management is actively reviewing the results of the process, master-data listings, time-evaluation reports, payroll simulations, and disbursement reconciliations and resolving any exceptions found. A single point of access failure and a single missed management review represent different failure modes, so the domain tag stays attached to every row even though the controls are now tested and reported together.

Consolidated Control Matrix

Reading the Matrix

Every control in the matrix is documented the same way, no matter which domain it belongs to. You get a plain description of what the control is supposed to do, whether it’s meant to prevent a problem or catch one after the fact, whether a person or the system is doing the work, how risky it is, and a quick summary of how to test it. In the full working paper, each row also points to the exact test step and evidence tab where the sampling and results live and wraps up with a simple call: effective or not. If a control doesn’t hold up, the paper doesn’t just note that and move on, it records what went wrong, any backup control that’s catching the risk in the meantime, and management’s plan and deadline to fix it. That finding stays open until someone actually goes back and confirms the fix worked.

Read straight through, the matrix basically tells the story of one pay period, start to finish. HR1 makes sure the people being added to the system are real employees. HR2 makes sure the people leaving are actually taken off. HR3 through HR5 check that hours worked are captured in full and on time. HR6 is about the payroll run itself making sure it’s controlled properly and that only the right people can trigger it. HR7 checks that what employees were actually paid matches what was recorded. And HR8 ties it all together by confirming that changes to master data keep getting reviewed and that no one person can do too much on their own.

Disclaimer

This article is provided for educational and informational purposes only. Organizations should assess their own business, security, and compliance requirements before making any authorization or access control decisions.

An SAP Fiori Catalog is a collection of tiles (app shortcuts) grouped together and made available to users on the SAP Fiori Launchpad. Think of it as a curated “app library” — you define which apps belong together, configure their navigation targets, and then expose them to specific users through roles and authorization.

A catalog is the backbone of the Fiori Launchpad experience. Without a properly configured catalog:

• Users won’t see tiles on the Launchpad

• Navigation between apps (semantic object routing) won’t work

• Backend OData services won’t be authorized correctly

2. Key Terminology & Quick Reference

Before diving into the steps, familiarize yourself with these key values used throughout the process:

3. End-to-End Process Overview

The entire catalog creation process spans 12 logical steps across 3 phases:

Step 1  → Fiori App Library (find your target app)
Step 2  → Collect App Details (Semantic Object, Action, OData service)
Step 3  → Plan IDs (catalog ID, tile ID, target mapping ID)
Step 4  → Create Transport Request (SE10)
Step 5  → Create Catalog (/UI2/FLPD_CUST)
Step 6  → Add Business Catalog as Reference
Step 7  → Configure Target Mapping
Step 8  → Create Space & Page (/UI2/FLP)
Step 9  → Create PFCG Role (PFCG)
Step 10 → Add OData Services (IWSG + IWSV)
Step 11 → Generate Profile & Assign to User
Step 12 → Test on Launchpad

Critical Rule: Every step that creates or modifies configuration must be linked to a Transport Request before saving. Never skip this changes without a transport can’t be moved to production.

4. Phase 1 – Design: Launchpad Designer

T-Code: /UI2/FLPD_CUST

This phase involves creating your catalog and configuring the tile that users will see.

Step 1: Research in the Fiori App Library

Before touching any T-Code, go to the SAP Fiori Apps Reference Library (apps.sap.com/fiori) and search for your target app. You need to collect:

• The Semantic Object (e.g., InternalSales)

• The Semantic Action (e.g., displayOverviewPage)

• The OData Service name (e.g., SD_F2200_OVP_ISR_SRV)

• The SAP Business Catalog it belongs to (e.g., SAP_SD_BC_SALES_OVP_DISPL)

Step 2: Plan Your IDs

Before creating anything, plan your naming convention:

• Catalog ID: Use a Z_ prefix (e.g., Z_MY_SALES_CATALOG)

• Transport Request: Create this first via SE10

Step 3: Create the Transport Request

T-Code: SE10

1. Open SE10

2. Click Create

3. Select Workbench Request or Customizing Request as appropriate

4. Give it a description: "Fiori Catalog - My Sales Overview"

5. Save and note down the transport number (e.g., DEVK900123)

You will need this transport number at every subsequent step.

Step 4: Open Launchpad Designer

T-Code: /UI2/FLPD_CUST

1. Navigate to /UI2/FLPD_CUST (Launchpad Designer — Customer Scope)

2. You’ll see the Catalogs section on the left panel

3. Click the “+” icon to create a new catalog

Step 5: Create a New Catalog

1. Enter your Catalog ID (e.g., Z_MY_SALES_CATALOG)

2. Enter a Title (e.g., My Sales Overview Catalog)

3. When prompted, assign it to your Transport Request created in SE10

4. Save the catalog

Step 6: Add the SAP Business Catalog as a Reference

This is the key step where the tile gets created:

1. Inside your newly created catalog, click “Add Reference”

2. Search for the SAP business catalog: SAP_SD_BC_SALES_OVP_DISPL

3. Drag and drop the business catalog into your catalog area

4. This automatically creates a tile referencing the SAP standard app

Why a reference? Using a reference (instead of a copy) means your tile stays in sync with SAP updates. The tile points back to the SAP catalog rather than duplicating it.

Step 7: Configure the Target Mapping

Target Mappings define where the tile navigates to when clicked.

1. In Launchpad Designer, click on Target Mappings tab within your catalog

2. Click “+” to add a new target mapping

3. Fill in:

   • Semantic Object: InternalSales

   • Action: displayOverviewPage

   • Application Type: SAPUI5 Application

   • Application ID: (your Fiori app ID)

4. Assign to Transport Request

5. Save

5. Phase 2 – Layout: Space & Page Management

T-Code: /UI2/FLP

After creating the catalog and its tiles, you need to define where on the Launchpad the tiles will appear. This is done through Spaces and Pages.

Understanding Spaces & Pages

• A Space is like a tab or section on the Launchpad (e.g., “Sales” tab)

• A Page lives inside a Space and holds the actual tile layout

• Users see Spaces as navigation items; they see Pages as the content within each Space

Step 8: Create a Space

T-Code: /UI2/FLP

1. Navigate to /UI2/FLP

2. Click Spaces in the menu

3. Click “New” to create a Space

4. Enter:

   • Space ID: Z_SALES_SPACE

   • Title: Sales

5. Assign to Transport Request

6. Save

Step 9: Create a Page within the Space

1. Inside the Space you just created, click “New Page”

2. Enter:

   • Page ID: Z_SALES_PAGE

   • Title: Sales Overview

3. In the page layout editor, click “Add Section”

4. Within the section, click “Add Tile”

5. Search for and select the tile from your catalog (Z_MY_SALES_CATALOG)

6. Arrange the tile layout as desired

7. Assign to Transport Request

8. Save

6. Phase 3 – Authorization: PFCG Role Setup

T-Code: PFCG

This is arguably the most critical phase. Without proper role configuration, users won’t be able to access the app even if the tile appears on the Launchpad.

Step 10: Create a New Role in PFCG

T-Code: PFCG

1. Open PFCG (Profile Generator)

2. Enter a new Role Name: Z_MY_SALES_OVERVIEW_ROLE

3. Click “Single Role” and press Enter

4. Give it a Description: "Role for My Sales Overview Fiori App"

5. Save and assign to Transport Request

Step 11: Add the Space to the Role (Menu Tab)

1. In PFCG, go to the Menu tab

2. Click “Transaction” → “SAP Fiori Tile”

3. Or click the “Fiori” button to add Fiori apps directly

4. Add your Space: Z_SALES_SPACE

5. Save

Step 12: Add OData Services (Authorization Tab)

This is the step many beginners miss. The tile appears but the app throws errors if OData services aren’t authorized.

1. In PFCG, go to the Authorizations tab

2. Click “Change Authorization Data”

3. You will add two types of OData services:

Frontend OData Service (IWSG)

1. In the Authorization Object search, find S_SERVICE (OData service authorization)

2. Add a new entry with:

   • Service Type: IWSG (Frontend Server Group)

   • Service Name: The service group associated with your app

3. This generates an S_SERVICE authorization object for frontend access

Backend OData Service (IWSV)

1. Add another S_SERVICE entry with:

   • Service Type: IWSV (Backend OData Service)

   • Service Name: SD_F2200_OVP_ISR_SRV

2. This authorizes the backend service call

Why two types? SAP Fiori has a two-tier architecture:

• Frontend (IWSG) handles the UI5 app delivery from the Frontend Server

• Backend (IWSV) handles the data retrieval from the Backend (ECC/S/4HANA) Both must be authorized separately.

Step 13: Generate the Profile and Assign to User

1. After adding all authorizations, click “Generate” (the shield icon)

2. Give the profile a name (usually auto-suggested based on role name)

3. Click “Generate” to create the authorization profile

4. Go to the User tab in PFCG

5. Enter the User ID of the user who should receive access

6. Set a validity date range

7. Click “User Comparison” to sync the role to the user

8. Save

7. T-Code Cheat Sheet

8. Interview Answer Framework

When asked “How do you create an SAP Fiori Catalog?” in an interview, structure your answer using this 3-Phase Framework:

Phase 1 – Design

“I open Launchpad Designer using /UI2/FLPD_CUST, create a new catalog, search for the relevant SAP Business Catalog (e.g., SAP_SD_BC_SALES_OVP_DISPL), and drag it in as a reference tile. I also configure the Target Mapping with the Semantic Object and Action so the tile knows where to navigate.”

Phase 2 – Layout

“I then go to /UI2/FLP to create a Space and a Page. I add the tile from my catalog into the Page, which makes it visible on the Launchpad when the user logs in.”

Phase 3 – Authorization

“Finally, I create an ABAP role in PFCG, add the Space to the Menu tab, and then add both the IWSG (frontend) and IWSV (backend) OData service authorizations. This generates the required S_SERVICE authorization objects. I generate the profile and assign the role to the user.”

Always end with: “And every step is linked to a Transport Request before saving, so changes can be properly transported to Quality and Production.”

9. Common Mistakes to Avoid

Summary

SAP Fiori Catalog creation follows a clear 3-phase approach:

1. Design (/UI2/FLPD_CUST) → Create catalog, add reference tile, configure Target Mapping

2. Layout (/UI2/FLP) → Create Space and Page so the tile appears on the Launchpad

3. Authorization (PFCG) → Create role, add Space, authorize IWSG + IWSV OData services, generate profile, assign to user

Master these three phases, know your 5 T-Codes in point no 7, and always remember to link every change to a Transport Request and you’ll be well-prepared for both real-world implementation and interview questions on SAP Fiori Catalog creation.

Often, security risks do not arise from sophisticated cyberattacks but from excessive or poorly controlled access. A user may be able to schedule background jobs under another user’s ID, a developer may retain access to production after a project is completed, or a temporary administrative authorization may remain assigned long after its intended purpose has ended. These seemingly minor oversights can create significant security, compliance, and audit concerns.

Regular SAP security audits play a crucial role in identifying such risks before they lead to data breaches, unauthorized system changes, segregation-of-duties conflicts, or business disruptions.

This article highlights sixteen critical SAP authorization objects that are frequently reviewed during security and compliance audits. Organized by risk category, it explains the purpose of each authorization object, the associated risks, key audit considerations, and recommended controls to help organizations strengthen their SAP security posture and maintain compliance with internal and regulatory requirements.

Batch Job Control (S_BTCH_JOB, S_BTCH_NAM, S_BTCH_ADM, S_BDC_MONI)

Background processing is often the least scrutinized layer of an SAP landscape — jobs run silently, at odd hours, under technical users nobody questions. That’s precisely why it’s attractive to abuse.

• S_BTCH_JOB governs the job lifecycle itself: create, release, cancel, delete. A user with broad release rights can push a sensitive report to execute without the normal approval chain.

• S_BTCH_NAM is more insidious — it lets a job run as someone else. Combined with a privileged technical account, this becomes a way to inherit authorizations the requesting user doesn’t actually have. Auditors should specifically cross-reference job logs against the user IDs the jobs executed under.

• S_BTCH_ADM is essentially “root” for batch processing — full visibility and control over every job in the system, regardless of owner. Treat any non-Basis assignment as a finding requiring justification.

• S_BDC_MONI controls SM35 batch input session monitoring. While less powerful than the others, it allows reprocessing of failed mass-upload transactions — a vector for re-injecting data that was previously rejected for valid reasons.

Audit tip: Pull a sample of jobs scheduled under SAP, DDIC, or other system accounts and verify each was triggered by an authorized process, not a regular user exploiting S_BTCH_NAM.

User and Role Administration (S_USER_AGR, S_USER_GRP, S_USER_PRO)

This cluster is the classic “who watches the watchmen” problem. Anyone holding broad rights across all four objects can effectively create a user, build a role with whatever permissions they like, assign it to themselves, and clean up the trail.

• S_USER_AGR (role admin) and S_USER_PRO (profile admin) are particularly dangerous in combination profiles bypass the more transparent role-based assignment process and can grant access directly, often without the same approval workflow.

• S_USER_GRP restricts user maintenance to specific user groups, which is a useful control when configured correctly, but a gap when group assignments are too broad (e.g., an admin team that can maintain “all users” rather than only their designated business unit).

Audit tip: The real test isn’t whether one person has all four it’s whether the combination across a team violates segregation of duties. The person who approves access requests should not also be the person who can technically grant them unchecked.

Development and Code Execution (S_DEVELOP, S_PROGRAM)

• S_DEVELOP is effectively a master key to the ABAP Workbench SE38, SE80, debugging with change capability, and more. In a development system, this is normal. In production, it’s a five-alarm finding: it means someone can write and run arbitrary code against live business data, often with the ability to debug-and-replace variables in running processes (a known privilege-escalation technique via debugger).

• S_PROGRAM is more nuanced because its risk depends entirely on which programs are in scope. A user authorized to execute a narrow set of reports via SUBMIT is low-risk; a user authorized for program group (*) can run anything, including undocumented or custom programs that bypass standard transaction controls entirely.

Audit tip: For S_DEVELOP in production, ask not just “who has it” but “has it ever been used” system logs (SM20/STAD) can show whether dormant access has actually been exercised, which often surfaces unauthorized changes that were never logged through transport management.

Table and Cross-System Configuration (S_TABU_DIS, S_TABU_CLI)

• S_TABU_DIS controls table maintenance grouped by authorization group — essentially a permission layer over SM30/SM31. The critical detail auditors miss is the activity value: ACTVT 03 (display) is informational risk, but ACTVT 02 (change) on the wrong table group, say, payroll configuration or pricing tables , is a direct path to financial manipulation.

• S_TABU_CLI is the nuclear option: cross-client maintenance means a change in one client ripples across every client on that system, including production. This authorization should be vanishingly rare outside Basis, and any assignment to a functional or business user is almost always a misconfiguration rather than a deliberate decision.

Audit tip: Don’t just check who has S_TABU_DIS, map the authorization groups assigned against the actual tables in those groups, and flag any group containing both “harmless” config tables and sensitive ones (a common design flaw that grants more than intended).

Operating System and Infrastructure Reach (S_DATASET, S_RZL_ADM, S_ADMI_FCD, S_LOG_COM)

This is where SAP authorizations stop being “application risk” and start being “infrastructure risk.”

• S_DATASET governs file-level access at the OS layer through SAP read, write, delete. Interfaces legitimately need this to exchange files, but unscoped path authorizations (wildcards on directory paths) mean a user could potentially read configuration files, log files, or other sensitive data well outside SAP’s normal data model.

• S_RZL_ADM covers CCMS the technical nervous system for monitoring and managing application servers. Misuse here is less about data theft and more about availability: someone with this access could disrupt workload distribution or take servers offline.

• S_ADMI_FCD is a grab-bag of administrative switches, several of which deserve individual attention: client copy authorizations (which can overwrite entire clients), spool administration (access to potentially sensitive print/output data across the system), and system monitoring functions that can reveal configuration details useful for further attacks.

• S_LOG_COM is arguably the most dangerous object on this entire list, it allows SAP to trigger operating-system-level commands defined in SM69. If those command definitions aren’t tightly controlled, this becomes a direct path from the SAP application layer to the underlying OS shell.

Audit tip: For S_LOG_COM, don’t stop at “who has the authorization” review the SM69 command table itself. A command defined with a wildcard parameter or shell metacharacter handling issues can turn a “harmless” authorization into arbitrary command execution.

Closing Thoughts

These authorization objects are essential for running and managing an SAP system, but with great access comes greater responsibility. The goal of an SAP audit is not to remove critical permissions, but to ensure they are assigned only where there is a valid business need and are reviewed regularly. When access is not properly governed, excessive privileges can accumulate over time, increasing the risk of security incidents, compliance violations, and audit findings. Regular reviews and adherence to the principle of least privilege are key to maintaining a secure and compliant SAP environment.

Disclaimer

This article is provided for educational and informational purposes only. Organizations should assess their own business, security, and compliance requirements before making any authorization or access control decisions.