SAP Security & GRC — Complete Notes | Authorization | PFCG | GRC 12

📚 SAP Security & GRC — Overview

SAP Security is the practice of controlling who can access what data and functions within SAP systems. In enterprises running SAP ERP, improper security leads to financial fraud, data breaches and regulatory non-compliance (SOX, GDPR, ISO 27001) — worth millions in fines.

SAP Security professionals are among the most stable and highest-paid in enterprise IT — ₹8–40 LPA in India — because every large SAP customer needs them permanently.

🔐

Authorization Concept

How SAP decides to allow or deny every user action — the golden rule

👤

User Management

5 user types, SU01, password policy, mass changes with SU10

🛠️

PFCG Role Design

Single, composite, derived roles — the core of SAP security work

📋

Auth Objects

Authorization objects, fields, values — SU24, ACTVT explained

⚖️

GRC Access Control

4 components — ARA, ARM, EAM, BRM — the full GRC picture

⚡

SOD Analysis

Segregation of Duties — fraud prevention, risk levels, remediation

🔥

Firefighter EAM

Emergency access — FF IDs, controller review, audit trail

🏘️

S/4HANA Security

What changes from ECC — Business Partner, Fiori, ACDOCA

📱

Fiori Security

3-layer architecture — backend PFCG + OData + Launchpad

❓

Interview Q&A

80+ real questions from EY, Deloitte, IBM, Accenture

💡 How to use this page: Click any topic in the left sidebar. All notes load instantly with no page reloads. Every section has original SVG diagrams, examples and interview questions. Use Prev / Next buttons to go in order.

🔐 SAP Authorization Concept

Beginner → Intermediate

The Authorization Concept is the framework that governs how SAP decides whether to allow or deny any user action. Every time a user clicks anything in SAP, an authorization check runs in the background. Understanding this perfectly is the most critical SAP Security skill.

💡 The Golden Rule of SAP Security: Every user should have the minimum access required to perform their job — and nothing more. This is the Principle of Least Privilege (PoLP) and it is the foundation of all SAP security design.

How the Authorization Check Works — Step by Step

SAP Security — 3-Layer Architecture

Key SAP Security Terms

Authorization Object

A container of related fields controlling access to a specific SAP function. Over 1,000 standard objects exist. Example: S_TCODE controls transaction access; F_BKPF_BUK controls FI posting per company code.

Authorization Field

A specific attribute inside an authorization object. The ACTVT (Activity) field uses: 01=Create, 02=Change, 03=Display, 06=Delete, 08=Display+Change.

Authorization Check

The runtime security check when a user executes a function. If any check fails, the user sees an error. Transaction SU53 shows the exact failed check.

Role (Activity Group)

A collection of T-codes and authorization values defining what a user can do. Created in PFCG. A user can have multiple roles assigned.

Profile

The technical compilation of a role. Generated automatically in PFCG. Users get authorizations via profiles — never assigned directly.

User Buffer

In-memory cache of all authorization values for a logged-in user. Rebuilt at each login. Role changes only take effect after user logs out and back in.

SU53

Shows the LAST failed authorization check for a user — exact object, field and required value. First tool to use when a user reports an authorization error.

SUIM

SAP User Information System — reporting tool. Answer questions like: Who has SAP_ALL? Which users can run SU01? What does role X contain?

Important Profile Parameters

Parameter	Value	Purpose
`login/min_password_lng`	8 (minimum)	Minimum password length
`login/password_expiration_time`	90	Days before password expires
`login/fails_to_user_lock`	5	Wrong attempts before account locks
`login/no_automatic_user_sapstar`	1	Disable dangerous SAP* backdoor in ALL clients
`login/failed_user_auto_unlock`	1	Auto-unlock Dialog users at midnight (0 = never)
`auth/rfc_authority_check`	1	Enforce authorization checks in RFC calls
`rsau/enable`	1	Activate Security Audit Log (SM19)

👤 User Types & Management (SU01)

Beginner

SAP has five user types, each designed for a specific purpose. Choosing the wrong type is a common security mistake — e.g., running batch jobs under a Dialog user creates unnecessary audit exposure and locks if the password expires.

User Type	Can Log In?	Password Policy	Best Used For	Common Mistake
Dialog	YES — via SAP GUI	Full: expiry + complexity + history	Regular end users — daily work	Running background jobs as Dialog — password expires and job fails at 2 AM
System	NO — no interactive login	Date-based expiry only	Background jobs, RFC connections, batch processing	Assigning SAP_ALL — use minimum required authorizations
Communication	NO — only RFC	Date-based expiry only	RFC connections between SAP systems (System-to-System)	Not rotating passwords — interfaces fail silently
Service	YES — multiple people share	No auto-expiry — must manage manually	Self-service portals, anonymous internet transactions	Weak password or SAP_ALL — critical vulnerability
Reference	Cannot login at all	Not applicable — no password	Template for assigning profiles to multiple users	Using as a real user — reference users cannot log in

🚫 Audit Red Flag: Finding Dialog users running background batch jobs is an immediate red flag in any SAP security audit. Background jobs must run under System users with minimum authorizations. Use SM36 to check job owner.

SU01 — Key Actions

1

Create a new user — SU01 → Enter username → Click Create → Set user type, initial password, validity dates, roles and profiles → Save

2

Lock / Unlock a user — SU01 → Enter username → Click Lock (Ctrl+F5) or Unlock. Or use SU10 for mass lock/unlock.

3

Reset password — SU01 → Enter username → Logon Data tab → Set new Initial Password → Save. User must change at next login.

4

Assign roles — SU01 → Enter username → Roles tab → Add role names → Save. Role change takes effect after user logs out and back in.

5

View last login — SU01 → Enter username → Logon Data tab → Shows last successful login date/time. Use for identifying dormant users.

6

Mass changes — SU10 — SU10 allows you to lock/unlock, change passwords and assign roles to MULTIPLE users simultaneously. Essential for project go-lives.

🛠️ Roles & Profiles — PFCG Deep Dive

Intermediate

Roles (formerly Activity Groups) are the primary mechanism for granting access in SAP. Transaction PFCG (Profile Generator) creates, maintains and assigns roles. This is the most hands-on skill in SAP Security.

Types of Roles

Single Role

Contains T-codes and authorizations for ONE specific business function. Maps to one generated profile.

Example: Z_FI_GL_DISPLAY_SR — only display GL documents.

Composite Role

Combines MULTIPLE single roles into one package for easier assignment. Contains no authorizations itself — just references.

Example: ZC_FI_ACCOUNTANT groups Display, Post and Report single roles.

Derived Role

Inherits menu and T-code list from a Master Role. Has DIFFERENT organizational values (company code, plant, sales org).

Example: Z_FI_POST_CC1000 derived from Z_FI_POST_MASTER for company code 1000.

PFCG Role Design — 5 Steps

Role Naming Convention — Best Practice

Pattern	Example	Meaning
`Z_[MOD]_[FUNCTION]_SR`	`Z_FI_GL_ACCOUNTANT_SR`	Custom(Z) · FI module · GL Accountant function · Single Role
`Z_[COUNTRY]_[MOD]_[JOB]_SR`	`Z_IN_MM_BUYER_SR`	India · MM module · Buyer job · Single Role
`ZC_[NAME]`	`ZC_FI_ALL_ACCOUNTANTS`	Composite role grouping multiple FI single roles
`ZD_[MASTER]_[ORG]`	`ZD_FI_POST_CC1000`	Derived from Z_FI_POST master, org value = company code 1000

📋 Authorization Objects & Fields

Intermediate

Most Important Authorization Objects

Object	Controls	Key Fields	Example
`S_TCODE`	Transaction code access	TCD (Transaction code)	TCD = FB01 allows user to execute FB01
`F_BKPF_BUK`	FI document posting by company code	BUKRS (Company code), ACTVT (Activity)	BUKRS=1000, ACTVT=01 allows posting in company 1000
`F_BKPF_KOA`	FI document by account type	KOART (Account type), ACTVT	KOART=D (Customer), ACTVT=03 allows display only
`M_MSEG_BWA`	Goods movement type	BWART (Movement type), ACTVT	BWART=101 (Goods Receipt from PO)
`P_ORGIN`	HR — org data access	VDSK1 (Org key), INFTY (Info type), SUBTY	Restrict HR data by org unit and info type
`S_DEVELOP`	ABAP development access	DEVCLASS (Package), ACTVT, OBJTYPE	ACTVT=02 means Change — dangerous in production!
`S_ADMI_FCD`	Basis/system administration	S_ADMI_FCD (Admin function)	Controls SM50, SM51, SM69 etc.
`S_TABU_DIS`	Table browser access	DICBERCLS (Auth group), ACTVT	Controls SE16, SE16N table display

ACTVT Field — Activity Values

01

Create

02

Change

03

Display

06

Delete

08

Display + Change

16

Execute

23

Maintain

*

All Activities

🚫 Warning — ACTVT=* (Wildcard): Assigning * to ACTVT means ALL activities — including Delete and Change. This is an automatic audit finding. Always assign specific activity values. Never use wildcards in production roles.

🔍 Troubleshooting Authorization Issues

Intermediate

Step-by-Step Troubleshooting Process

1

User reports authorization error — Ask them to immediately run SU53 (or you run SU53 for them via SU53 → Edit → Display Other User). Do this immediately — SU53 only shows the LAST failed check and gets overwritten with the next action.

2

Read SU53 output carefully — SU53 shows: Authorization Object that failed (e.g., S_TCODE), the specific Field values required vs what the user has. This tells you exactly what is missing.

3

Check user's current roles in SU01 — Open SU01 for the user, go to Roles tab. See which roles are assigned. Are the correct roles there? Are the validity dates correct (not expired)?

4

Identify which role should contain the authorization — Based on the user's job function, which role should have this access? Check existing roles with PFCG or SUIM.

5

Fix in PFCG — add missing authorization — Open the role in PFCG, go to Authorizations tab, find the failing object, add the correct field values. Save and GENERATE the profile.

6

Test and document — Ask the user to log out completely and log back in (user buffer refreshes). Test the original action. Document the change with a change ticket for audit trail.

SUIM — Key Reports You Must Know

Scenario	SUIM Path	What It Shows
Who has SAP_ALL in production?	Users → By Profiles → Enter SAP_ALL	All users with the dangerous SAP_ALL profile — immediate audit finding
Who can run transaction SU01?	Users → By Transaction Code → Enter SU01	All users who can create/modify other users — key SOD risk
What access does user X have?	Users → By Username → Enter username	Complete role and authorization picture for one user
Which users have role Z_FI_POST?	Roles → By Role Name → Enter role name	All users currently assigned to a specific role
Who has access to company code 1000?	Users → By Authorization Values → F_BKPF_BUK, BUKRS=1000	Everyone who can post to that company code
Find dormant users	Users → By Logon Date → Users who haven't logged in since X date	Users to lock for security — reduce attack surface

⚖️ SAP GRC Access Control — Complete Overview

Intermediate → Advanced

SAP GRC (Governance, Risk and Compliance) Access Control is a separate SAP product installed alongside your SAP ERP system. It provides automated, auditable controls for managing user access risks — mandatory for SOX, GDPR and ISO 27001 compliance.

GRC vs Manual Security — Why GRC?

Aspect	Without GRC (Manual)	With GRC Access Control
SOD Detection	Manually review spreadsheets — weeks of work, error-prone	Automated real-time analysis against 200+ risk definitions in seconds
Access Requests	Email chains, no audit trail, long delays	Structured workflow with approval stages, auto-provisioning, complete log
Emergency Access	Give permanent access (risky) or struggle to respond	FF IDs with automatic logging, controller review within 24 hours
Role Management	Roles created inconsistently, no lifecycle management	Standardised methodology, automated review cycles, naming governance
Compliance Reports	Manual extraction and formatting — days of work	One-click SOX, GDPR, ISO 27001 compliance reports always ready

📊 ARA — Access Risk Analysis

Intermediate

ARA is the heart of SAP GRC. It identifies Segregation of Duties (SOD) conflicts and critical access risks by comparing user/role access against a predefined Rule Set. Every SOX-compliant SAP customer uses ARA.

1

Rule Set — A library of business risk definitions. Each risk specifies two conflicting business functions (e.g., Create Vendor AND Process Payment). SAP ships the standard Global Rule Set with 200+ predefined risks. Companies customise it for their industry and regulatory requirements.

2

Risk Levels — Critical (must remediate immediately — no mitigation), High (remediate within 30 days or mitigate), Medium (mitigate or remediate within 90 days), Low (monitor quarterly). Risk levels are assigned in the Rule Set and drive remediation urgency.

3

Analysis Types — User-level analysis (current state — what does this user have?), Role-level analysis (preventive — would this role create a risk?), HR org analysis (org-based risk by position). Always run both user and role level.

4

Remediation — Remove one of the conflicting access sets from the user's roles. This is the cleanest solution — preferred by auditors.

5

Mitigation — When removal is not feasible (small team, key person), document a compensating control: "Monthly manager review of vendor payment report." Mitigations need risk owner approval and annual review. Mitigations do NOT eliminate the risk — they document that it is managed.

6

Continuous Monitoring — Schedule ARA reports to run weekly or monthly. Assign risk owners who review and sign off. New SOD conflicts must be caught before users are provisioned — use preventive checks in ARM workflow.

🕐 ARM — Access Request Management

Intermediate

ARM provides a structured, auditable workflow for requesting, approving and provisioning SAP user access. It replaces informal email chains with a governed process — every step logged, every approval documented.

ARM Workflow — End to End

1

Request Initiation — The user or their manager submits an access request in GRC — specifying what access is needed and the business justification. HR new hire process can trigger requests automatically.

2

Preventive SOD Check — Before routing for approval, ARM runs an ARA check against the requested access. If a Critical SOD conflict is found, the request is blocked. This is prevention — catching issues BEFORE access is granted.

3

Approval Routing (MSMP) — Multi-Stage Multi-Path (MSMP) workflow routes the request to the correct approvers based on business rules — manager, role owner, security team, risk owner. Each stage has SLA timers.

4

Auto-Provisioning — Once all approvals are complete, ARM can automatically create the user in SU01 and assign the approved roles — no manual step needed. Dramatically reduces provisioning time.

5

Confirmation & Audit Log — The requester receives confirmation. Every action, approval, timestamp and comment is permanently logged in GRC for SOX audit evidence. Logs cannot be modified.

💡 Why ARM Matters for SOX: SOX Section 302 requires management to certify that access controls are operating effectively. Without ARM, you cannot prove who approved what access and when. With ARM, you have an immutable, timestamped approval trail for every user access grant.

🔥 EAM — Emergency Access Management (Firefighter)

Advanced

Firefighter (EAM) provides a controlled mechanism for granting temporary elevated access during production emergencies — while maintaining a complete audit trail. Without EAM, companies either give permanent access (risky) or have no secure way to respond to 2 AM production crises.

1

FF ID naming must be meaningful — FF_BASIS_PROD, FF_FI_MONTH_END — never generic names like FFID01 or TEMP. Descriptive names make logs readable and audits easier.

2

Reason codes are MANDATORY — Users must enter a valid reason code AND reference number (incident ticket) before logging in with FF ID. Without this, logs are meaningless.

3

Controller review within 24 hours — This is a hard requirement. The controller must acknowledge every FF usage log. Unreviewed logs are an immediate SOX finding.

4

FF IDs should be reviewed quarterly — Inactive FF IDs (not used in 90 days) should be locked or deleted. Unused privileged IDs are an audit vulnerability.

5

Never give permanent FF access — FF access is temporary — create for the emergency, use, and revoke immediately. Permanent FF access defeats the entire purpose of EAM.

👔 BRM — Business Role Management

Intermediate

BRM provides an end-to-end lifecycle for managing SAP roles — from creation and naming governance to periodic reviews and decommissioning. It bridges the gap between business language (job functions) and technical SAP roles.

BRM Role Lifecycle

1

Define Business Roles — Map job functions (e.g., "Accounts Payable Clerk") to required SAP access. Business owners define what access each job needs — not the IT team alone.

2

Design & Name Roles — Security team translates business requirements into PFCG technical roles following naming conventions. BRM stores the mapping between business roles and technical roles.

3

Risk Assessment — Before deploying, run ARA against the new role to identify SOD risks. Remediate or document mitigations before go-live.

4

Periodic Role Reviews — BRM schedules automatic reminders for role owners to review their roles — typically annually or when the business function changes.

5

User Access Certification — Managers certify that each of their team members still needs the access they have. This is the "access recertification" required by SOX.

6

Decommission Old Roles — BRM identifies roles with no users assigned (orphaned roles) for cleanup. Unused roles are a security risk and audit finding.

⚡ SOD — Segregation of Duties

Intermediate → Advanced

Segregation of Duties ensures no single individual controls all steps of a critical business process — because unchecked access creates undetected fraud opportunities. SOD is a mandatory requirement of SOX, COSO, ISO 27001 and most ERP audit frameworks.

🚫 Classic Fraud Example — Procure to Pay (P2P): If one person can CREATE a vendor (FK01) + CREATE a purchase order (ME21N) + APPROVE the PO + POST goods receipt (MIGO) + ENTER the invoice (MIRO) + RUN the payment (F110) — they can fabricate the entire cycle, pay a ghost vendor and steal company money. This is exactly what SOX Section 302 and 404 are designed to prevent.

Top SOD Conflicts Every SAP Security Professional Must Know

Business Process	Function 1	Function 2	Fraud Risk	Risk Level
Procure to Pay	Create Vendor (FK01)	Process Payment (F110)	Create ghost vendor and pay them	Critical
Procure to Pay	Create PO (ME21N)	Approve PO (ME29N)	Self-approve fraudulent purchase orders	Critical
Financial Accounting	Post Journal Entry (FB01)	Approve Journal Entry	Manipulate financial records undetected	Critical
HR / Payroll	Create Employee (PA40)	Process Payroll (PC00)	Add ghost employees to payroll	Critical
Order to Cash	Create Customer (FD01)	Post Customer Invoice (FB70)	Raise fake invoices, steal payments	High
Basis / Security	Create User (SU01)	Assign Roles (PFCG)	Grant excessive access to self or others	Critical
Asset Management	Create Asset (AS01)	Post Depreciation (AFAB)	Manipulate asset values on balance sheet	High

🏘️ SAP S/4HANA Security

Advanced

SAP ECC goes End of Standard Maintenance in 2027. Every company must migrate to S/4HANA. This is the biggest SAP security challenge in 20 years — and the biggest opportunity for SAP Security professionals who understand the differences.

Area	SAP ECC	SAP S/4HANA	Security Impact
User Interface	SAP GUI (T-codes)	SAP Fiori Launchpad (Apps)	Need 3 auth layers: Backend PFCG + OData service + Fiori catalog/group
Data Model	Separate BKPF/BSEG, MKPF, etc.	Universal Journal (ACDOCA)	Some FI/CO auth objects changed — all roles need retesting
Business Partner	Separate Vendor (LFA1) + Customer (KNA1)	Unified Business Partner (BP)	New auth objects: BP_BPTC, BUPR_BUPA — must add to Vendor/Customer roles
T-Codes	Most T-codes work	Many T-codes deprecated or replaced by Fiori apps	Roles built around T-codes may be partly invalid — redesign needed
Embedded Analytics	Separate BI/BW system	Built into S/4HANA HANA DB	New auth objects for CDS views and analytical reports

💡 Migration Best Practice: Do NOT migrate old ECC roles directly to S/4HANA. Build roles from scratch aligned to business functions and Fiori app catalogues. Use SAP's Fiori Apps Reference Library to understand which auth objects each app requires. Plan for 30–50% more security effort in S/4HANA projects vs ECC.

📱 SAP Fiori Security — 3-Layer Architecture

Advanced

Fiori is the browser-based UI for S/4HANA. Security requires three separate layers — all three must be correctly configured for a user to access a Fiori app. Missing any one layer results in the app not appearing or throwing an authorization error.

💡 Fiori Debugging Checklist: When a user cannot access a Fiori app, check in this order:
(1) Is the Fiori catalog/group assigned? Check /UI2/FLPD_CONF.
(2) Is the OData service activated? Check /IWFND/MAINT_SERVICE.
(3) Run SU53 in the backend for the traditional auth check.
All three layers must be green for the app to work fully.

📋 Security Audit Checklist — 25 Critical Checks

Advanced

Use this checklist before any internal or external audit. All Critical and High findings must be resolved before auditors arrive — they will definitely look for these.

CRITICAL SAP_ALL profile assigned to any user in production — immediate critical finding.

CRITICAL SAP_NEW profile assigned — removes checks for all new functionality.

CRITICAL Debug access (S_DEVELOP ACTVT=02) for non-Basis users in production.

CRITICAL Default passwords unchanged — SAP*, DDIC, SAPCPIC in any production client.

CRITICAL Shared user IDs — multiple people using one login. Individual accountability eliminated.

HIGH Firefighter logs not reviewed by controller within 24 hours of usage.

HIGH SU01 access — who can create/modify users must be tightly controlled.

HIGH Password policy not enforced: login/min_password_lng below 8.

HIGH Dormant users (no login in 90+ days) still active.

HIGH Critical SOD conflicts without approved mitigating controls.

HIGH Dialog users running background batch jobs — must be System users.

HIGH User Admin AND Role Admin in the same person — SOD in security team itself.

MEDIUM Security Audit Log (SM19) not activated in production.

MEDIUM User access recertification not completed in last 12 months.

MEDIUM Security role changes not going through proper change management.

MEDIUM GRC compliance reports not scheduled or reviewed monthly.

MEDIUM SUIM reports not run to proactively identify excessive access.

MEDIUM Table display (S_TABU_DIS) for sensitive config tables not restricted.

MEDIUM Print and spool access (S_SPO_DEV) not restricted.

LOW Role naming convention not consistent — hinders maintenance and audits.

LOW Unused roles (no users assigned for 180+ days) not cleaned up.

LOW Authorization documentation not maintained for custom Z/Y roles.

LOW Test users from go-live projects still active in production.

LOW GRC risk definitions not reviewed and updated in last 12 months.

LOW Inactive FF IDs (unused 90+ days) still enabled.

❓ SAP Security Interview Q&A

Most frequently asked questions at EY, Deloitte, PwC, IBM, Accenture and SAP implementation partners. Click to reveal model answers.

Q1. Explain the SAP authorization concept end to end. +

Model Answer:

When a user executes any SAP function, the system runs an AUTHORITY-CHECK statement in the ABAP program. First, S_TCODE is checked — if the transaction code is not in the user's roles, access is denied immediately. If S_TCODE passes, SAP checks ALL authorization objects relevant to that transaction against the user's profile values. If ANY object check fails, access is denied. Transaction SU53 shows the exact object, field and required value for the last failed check. The security team uses PFCG to add the missing authorization to the role, generates the profile, and the user logs out and back in to rebuild their user buffer with the new values. The chain is: User action → AUTHORITY-CHECK in ABAP → S_TCODE check → Object checks → Grant or Deny.

Q2. What is the difference between Single, Composite and Derived Roles? +

Model Answer:

A Single Role contains transactions and authorizations for one specific business function — it generates one profile. A Composite Role combines multiple single roles into one assignment package — it has no authorizations itself, just references. Assigning a composite role assigns all its included single roles simultaneously. A Derived Role inherits its menu and T-code list from a Master Role but has different organizational-level values (company code, plant, sales org). This is the most efficient design for multi-company environments — create the menu once in the master role, derive roles for each org unit with different company code values. Changes to the master role menu automatically propagate to all derived roles.

Q3. What is SOD and give examples of critical SOD conflicts in SAP? +

Model Answer:

Segregation of Duties ensures no single person controls all steps of a critical business process, preventing undetected fraud. Critical SAP examples: P2P — same person creates vendor (FK01) AND processes payment (F110) can create ghost vendors and steal money. Financial — same person posts journal entries AND approves them can manipulate accounts undetected. Security — same person creates users (SU01) AND assigns roles (PFCG) can grant themselves excessive access. SOD is enforced in SAP GRC ARA by comparing user access against a Rule Set of 200+ conflicting function pairs. Violations are categorized as Critical, High, Medium or Low. Critical violations must be remediated; others can be mitigated with compensating controls.

Q4. What is SAP GRC Firefighter and how does it work? +

Model Answer:

Firefighter (EAM) provides temporary elevated access for production emergencies with a complete audit trail. Standard process: (1) A production emergency occurs. (2) The user requests a Firefighter ID from the FF Owner — typically via GRC workflow or phone in an emergency. (3) The FF Owner approves and assigns the specific FF ID. (4) The user logs in with the FF ID — every transaction executed and every table accessed is automatically logged. (5) The log is automatically emailed to the FF Controller, who MUST review and acknowledge within 24 hours. This is mandatory — unreviewed logs are an immediate SOX finding. (6) The access is revoked after the emergency is resolved. The key difference from permanent access: every action is logged, a second person (Controller) reviews everything, and access is temporary.

Q5. What changes in SAP security from ECC to S/4HANA? +

Model Answer:

Five major areas change: (1) Fiori UI — security now requires three layers: traditional PFCG backend roles, OData service activation (/IWFND/MAINT_SERVICE), and Fiori catalog/group assignment (/UI2/FLPD_CONF). All three must be configured. (2) Business Partner — replaces separate Vendor and Customer masters. New authorization objects BP_BPTC and BUPR_BUPA must be added to affected roles. (3) Universal Journal — ACDOCA replaces BKPF/BSEG and other FI/CO tables; some authorization objects changed. (4) T-code deprecation — many classic T-codes replaced by Fiori apps, making T-code-centric roles partly invalid. (5) Embedded Analytics — CDS views introduce new authorization concepts not present in ECC. Best practice: build new roles from scratch for S/4HANA rather than migrating ECC roles.

Q6. How do you troubleshoot a missing authorization in SAP? +

Model Answer:

Step 1: Ask the user to immediately run SU53 after the error — it captures the exact authorization object, field and required value that was missing. Step 2: Note the failing object (e.g., F_BKPF_BUK, field BUKRS, required value 1000). Step 3: Check the user's roles in SU01 to understand current access. Step 4: Identify which role should contain this authorization based on the user's job function. Step 5: Open the role in PFCG, go to Authorizations tab, find the failing object, and add the correct organizational value. Step 6: Generate the role profile (critical — without generation the change has no effect). Step 7: Ask the user to log out completely and log back in (user buffer refresh). Step 8: Test the original action. Step 9: Document the change with a change management ticket for audit trail. Never make production changes without a change ticket.

Q7. What is SUIM and what reports can you generate from it? +

Model Answer:

SUIM (User Information System) is SAP's built-in reporting tool for security-related information. Key reports: (1) Users with critical profiles — find all users with SAP_ALL or SAP_NEW (immediate audit findings). (2) Users who can execute a specific transaction — who can run SU01? FB01? (3) Transactions executable by a specific user — what can user JSMITH run? (4) Users assigned to a specific role — who has Z_FI_POSTING_SR? (5) Authorization object values — who has BUKRS=1000 in F_BKPF_BUK? (6) Locked users — list all locked accounts. (7) Dormant users — users who haven't logged in since a date. (8) Role contents — what does role Z_FI_POST contain? SUIM is used by security teams, internal audit and external auditors. Always run SUIM proactively before an audit to identify issues yourself before auditors do.

Q8. Explain the different types of SAP users and when to use each. +

Model Answer:

Five types: (1) Dialog — standard user for human-initiated interactive work via SAP GUI. Password policy fully applies — expiry, complexity, history. Use for all regular end users. (2) System — for background processing, batch jobs and RFC. Cannot log in interactively. Password expires only on a set date. Use for scheduled jobs and system-to-system interfaces. (3) Communication — for RFC connections between SAP systems. Similar to System but designed for system-to-system calls. (4) Service — allows multiple people to share one ID, typically for internet or portal scenarios. No automatic expiry — requires careful password management. Never assign excessive authorizations. (5) Reference — cannot log in at all. Used as a template to assign a standard profile set to other users. Common mistake: using Dialog users for batch jobs — password expires at 2 AM and the job fails. Always use System users for background processing.

🏅 SAP Security Certification Guide

All Levels

C_SECAUTH_20

SAP Certified Application Associate — SAP System Security & Authorizations

Duration	180 minutes
Questions	80 multiple-choice
Pass Mark	65% (52 correct)
Level	Associate
Prerequisites	6+ months SAP Security experience
Cost	approx. USD 500
Validity	5 years — recertification required

C_GRCAC_12

SAP Certified Application Associate — SAP Access Control (GRC) 12.0

Duration	180 minutes
Questions	80 multiple-choice
Pass Mark	65% (52 correct)
Level	Associate
Prerequisites	SAP GRC project experience
Cost	approx. USD 500
Validity	5 years

C_SECAUTH_20 Topic Weightage

Topic Area	Exam Weight	Study Priority
User Administration (SU01, user types, password policy)	15–20%	HIGH — always asked
Role & Profile Design (PFCG, SU24, naming conventions)	20–25%	HIGH — most marks here
Authorization Concept & Objects (checks, objects, fields)	15–20%	HIGH — conceptual foundation
Troubleshooting (SU53, SUIM, error analysis)	10–15%	MEDIUM — practical scenarios
GRC Overview & Integration	10–15%	MEDIUM
Security Audit & Monitoring (SM19, SM20, parameters)	10–15%	MEDIUM
S/4HANA & Fiori Security Basics	5–10%	LOW — but growing

📚 Best Preparation Path: 3–4 months hands-on SAP system practice + studying these notes. SAP offers a free 30-day trial sandbox via SAP Learning Hub. Practice creating roles in PFCG, troubleshooting with SU53, and running SUIM reports. Theoretical knowledge alone is insufficient — the exam tests practical understanding with real-scenario questions.

SAP Security & GRC
Complete Notes

📚 SAP Security & GRC — Overview

🔐 SAP Authorization Concept

How the Authorization Check Works — Step by Step

SAP Security — 3-Layer Architecture

Key SAP Security Terms

Important Profile Parameters

👤 User Types & Management (SU01)

SU01 — Key Actions

🛠️ Roles & Profiles — PFCG Deep Dive

Types of Roles

PFCG Role Design — 5 Steps

Role Naming Convention — Best Practice

📋 Authorization Objects & Fields

Most Important Authorization Objects

ACTVT Field — Activity Values

🔍 Troubleshooting Authorization Issues

Step-by-Step Troubleshooting Process

SUIM — Key Reports You Must Know

⚖️ SAP GRC Access Control — Complete Overview

GRC vs Manual Security — Why GRC?

📊 ARA — Access Risk Analysis

🕐 ARM — Access Request Management

ARM Workflow — End to End

🔥 EAM — Emergency Access Management (Firefighter)

👔 BRM — Business Role Management

BRM Role Lifecycle

⚡ SOD — Segregation of Duties

Top SOD Conflicts Every SAP Security Professional Must Know

🏘️ SAP S/4HANA Security

📱 SAP Fiori Security — 3-Layer Architecture

📋 Security Audit Checklist — 25 Critical Checks

❓ SAP Security Interview Q&A

🏅 SAP Security Certification Guide

SAP Certified Application Associate — SAP System Security & Authorizations

SAP Certified Application Associate — SAP Access Control (GRC) 12.0

C_SECAUTH_20 Topic Weightage

Ready for Live SAP Security Training?

SAP Security & GRCComplete Notes

📚 SAP Security & GRC — Overview

🔐 SAP Authorization Concept

How the Authorization Check Works — Step by Step

SAP Security — 3-Layer Architecture

Key SAP Security Terms

Important Profile Parameters

👤 User Types & Management (SU01)

SU01 — Key Actions

🛠️ Roles & Profiles — PFCG Deep Dive

Types of Roles

PFCG Role Design — 5 Steps

Role Naming Convention — Best Practice

📋 Authorization Objects & Fields

Most Important Authorization Objects

ACTVT Field — Activity Values

🔍 Troubleshooting Authorization Issues

Step-by-Step Troubleshooting Process

SUIM — Key Reports You Must Know

⚖️ SAP GRC Access Control — Complete Overview

GRC vs Manual Security — Why GRC?

📊 ARA — Access Risk Analysis

🕐 ARM — Access Request Management

ARM Workflow — End to End

🔥 EAM — Emergency Access Management (Firefighter)

👔 BRM — Business Role Management

BRM Role Lifecycle

⚡ SOD — Segregation of Duties

Top SOD Conflicts Every SAP Security Professional Must Know

🏘️ SAP S/4HANA Security

📱 SAP Fiori Security — 3-Layer Architecture

📋 Security Audit Checklist — 25 Critical Checks

❓ SAP Security Interview Q&A

🏅 SAP Security Certification Guide

SAP Certified Application Associate — SAP System Security & Authorizations

SAP Certified Application Associate — SAP Access Control (GRC) 12.0

C_SECAUTH_20 Topic Weightage

Ready for Live SAP Security Training?

SAP Security & GRC
Complete Notes