SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

SAP SECURITY CONSULTANT

Top 100 Real-Time Interview Questions & Answers
Comprehensive Preparation Guide for SAP Security Professionals

What This Guide Covers

Topic Area Questions Q#

SAP Security Fundamentals 10 Q1–Q10

User Administration 10 Q11–Q20
Roles and Profiles 15 Q21–Q35
Authorization Objects & Troubleshooting 15 Q36–Q50
SAP GRC & Compliance 15 Q51–Q65
Audit, Monitoring & Advanced Topics 15 Q66–Q80
S/4HANA, Cloud & Modern SAP Security 10 Q81–Q90
Scenario-Based & Behavioral Questions 10 Q91–Q100

Page 1 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

I. SAP Security Fundamentals

Q1: What is SAP Security and why is it important?
Answer: SAP Security is the practice of protecting SAP systems from unauthorized access, data
breaches, and misuse. It involves controlling user access, ensuring data integrity, and maintaining
compliance with regulations. It is critical because SAP systems store sensitive business data
including financial records, HR data, and strategic information.

Q2: What are the main components of SAP Security?

Answer: The main components include: User Administration (managing user accounts and
credentials), Authorization Management (roles, profiles, authorization objects), Audit and Monitoring
(logging and reviewing user activities), Network Security (protecting system communications), and
Compliance Management (ensuring adherence to regulations like SOX, GDPR).

Q3: What is the difference between Authentication and Authorization in SAP?

Answer: Authentication verifies the identity of a user (e.g., username/password, SSO, X.509
certificates) — it confirms WHO the user is. Authorization determines what an authenticated user is
allowed to do — it controls WHAT they can access. In SAP, authentication is handled via logon
settings while authorization uses roles and profiles.

Q4: What is a SAP Landscape and why does it matter for security?
Answer: A SAP Landscape refers to the set of SAP systems (typically Development, Quality,
Production). Security matters across the landscape because roles and transports must follow
proper change management. Changes should be created in Development, tested in Quality, and
transported to Production — never made directly in Production.

Q5: What is SNC in SAP and how does it enhance security?

Answer: SNC (Secure Network Communications) encrypts communication between SAP
components and external systems. It uses third-party security products (like Kerberos) to
authenticate and encrypt data in transit. SNC protects against eavesdropping and man-in-the-
middle attacks on SAP network communication.

Q6: Explain the SAP authorization concept.

Answer: SAP authorization works in layers: Authorization Objects define what checks are
performed during a transaction (e.g., which activity on which organizational object). Field values are
assigned to these objects. Objects are grouped into Authorization Profiles. Profiles are bundled into
Roles, and Roles are assigned to Users. When a user runs a transaction, SAP checks if they have
the required authorization values.

Q7: What is the purpose of transaction SM30 in security context?

Answer: SM30 is the Table Maintenance transaction used to edit customizing tables. From a
security perspective, access to SM30 must be tightly controlled as it can allow users to modify
critical configuration tables. The authorization object S_TABU_DIS or S_TABU_NAM controls which
tables a user can maintain, and unrestricted SM30 access is considered a critical risk.

Q8: What is a Transport in SAP and what are the security implications?
Answer: A Transport moves objects (including roles) from one system to another via the Transport
Management System (TMS). Security implications include: roles must only be transported through
proper channels (Dev → QA → Prod), security patches and role changes should be tested before
going to Production, and transports must be authorized by appropriate personnel to prevent
unauthorized changes.

Page 2 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

Q9: What is the significance of Client 000 in SAP?

Answer: Client 000 is the SAP reference client containing standard SAP configuration. It should be
highly secured because: changes here can affect all clients, many SAP standard programs run in
client 000, and it contains master data used as templates. Users should not have dialog access to
client 000 in Production environments.

Q10: What are RFC (Remote Function Call) connections and their security risks?
Answer: RFC connections allow SAP systems to communicate with each other or with external
systems. Security risks include: RFC destinations with stored passwords (type 3) can be exploited,
trusted RFC connections can be used to bypass authorization checks, and the authorization object
S_RFC controls which function modules can be called. RFC connections should be regularly
audited using SM59.

Page 3 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

II. User Administration

Q11: What are the different user types in SAP and when do you use each?
Answer: Dialog (A): Standard interactive user for human logon. System (B): Background
processing and RFC calls, no interactive logon. Communication (C): External RFC/CPIC calls, no
dialog logon. Service (S): Shared by multiple users for specific tasks, limited logging. Reference (L):
Not for logon — used to provide additional authorizations via role inheritance.

Q12: What is the difference between SU01 and SU10?

Answer: SU01 is for single user maintenance — create, modify, display, lock/unlock one user at a
time. SU10 is the mass user administration tool — apply changes (assign roles, lock/unlock, set
validity dates) to multiple users simultaneously. SU10 is efficient for bulk operations like locking all
users in a terminated department.

Q13: How do you create a user in SAP? Walk me through the process.
Answer: In SU01: Enter the username and click Create. Fill in Address tab (name, department).
Set Logon Data (user type, initial password, validity dates). Go to Roles tab to assign roles. Go to
Profiles tab if directly assigning profiles. Save. The user will be prompted to change password on
first login. Always document the business justification for audit purposes.

Q14: What is a user group in SAP and why is it important?

Answer: A user group (set in SU01, field 'User Group') is used to segregate administrative
responsibilities. It controls who can administer which users. The authorization object S_USER_GRP
uses the activity and user group fields to determine which administrators can create/modify users in
a specific group. This prevents administrators from granting themselves unauthorized access.

Q15: How do you handle a user who has left the organization?
Answer: Immediately lock the user account via SU01 (lock button) to prevent access. Remove or
time-limit role assignments. Notify relevant application owners. After a retention period (as per
policy), delete the user. Document all actions for audit trail. In GRC environments, trigger a leaver
workflow that automates these steps with approval tracking.

Q16: What is Central User Administration (CUA) and what are its benefits?
Answer: CUA allows centralized management of users across multiple SAP systems from a single
system. Benefits include: single point of user creation and role assignment, consistent user master
data across systems, reduced administration effort, and centralized audit trail. The central system
distributes user data to child systems via ALE/IDocs. Configured using SCUA transaction.

Q17: What are user validity dates and why are they important?
Answer: Validity dates (Valid From / Valid To) in SU01 define when a user account is active. They
are important for: contractors and temporary workers (automatically expire access), audit
compliance (demonstrating time-limited access), and system hygiene (preventing accumulation of
stale accounts). Role assignments also have validity dates, providing fine-grained time-based
access control.

Q18: What is the difference between locking and deleting a user?

Answer: Locking temporarily prevents a user from logging in but preserves all user data, role
assignments, and audit history. It is reversible. Deleting permanently removes the user master
record. Best practice: always lock first, keep for a retention period (typically 90 days or per company
policy), then delete. Deleting too quickly can cause audit and compliance issues.

Q19: What login parameters are important for SAP security?

Page 4 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

Answer: Key login parameters include: login/min_password_len (minimum password length),

login/password_max_idle_productive (password expiry for productive users),
login/fails_to_session_end (logon attempts before session termination), login/fails_to_user_lock
(attempts before account lockout), login/no_automatic_user_sapstar (controls SAP* emergency
user behavior). These are set via RZ10/RZ11.

Q20: What is the SAP* user and why is it a security risk?

Answer: SAP* is the default superuser in every SAP client. If the SAP* user master record is
deleted, SAP allows login with the hard-coded password 'pass' (or '06071992') with unrestricted
access. Security measures: always maintain an SAP* user master record in every client, set the
profile parameter login/no_automatic_user_sapstar=1, and set a strong non-default password for
SAP*.

Page 5 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

III. Roles and Profiles

Q21: What is the difference between a Single Role and a Composite Role?
Answer: A Single Role is built in PFCG and contains specific transactions, authorization objects,
and field values for a particular job task. A Composite Role is a container that bundles multiple
single roles together. Assigning a composite role to a user effectively assigns all its single roles.
Composite roles simplify user administration but make authorization analysis more complex.

Q22: What is a Derived Role and when would you use it?
Answer: A Derived Role inherits the transaction menu and authorization objects from a Parent Role
but has different organizational-level field values (e.g., company code, plant, sales organization).
Used when the same job function exists across multiple org units. Example:
'FI_ACCOUNTANT_1000' and 'FI_ACCOUNTANT_2000' both inherit from
'FI_ACCOUNTANT_PARENT' but differ in company code values.

Q23: What is PFCG and what are its main functions?

Answer: PFCG (Profile Generator) is the main transaction for creating and maintaining SAP roles.
Key functions include: creating/editing single and composite roles, managing the menu structure of
a role (which transactions appear in the user menu), maintaining authorization data (authorization
objects and field values), generating authorization profiles from role data, and assigning users to
roles.

Q24: What is the Authorization Profile and how is it related to a Role?

Answer: An Authorization Profile is automatically generated by PFCG when you save a role. It
contains the technical authorization data (authorization objects and field values). The profile is what
is technically stored in the user master record. While users are assigned roles in PFCG, it is the
profile behind the role that grants actual system access. Profile names are auto-generated (e.g., T-
AB123456).

Q25: Explain the process of creating a role in PFCG.

Answer: 1) Open PFCG, enter role name, click Create Single Role. 2) Add a description and menu
entries (transactions, reports). 3) Go to Authorizations tab, click Change Authorization Data. 4)
Maintain authorization objects — fill required field values using proposals from SU24. 5) Save and
generate the profile (green traffic light = fully maintained). 6) Assign users on the User tab. 7)
Transport to QA and then Production.

Q26: What does the 'traffic light' status in PFCG mean?

Answer: In the Authorizations tab of PFCG, the traffic light indicates the maintenance status: Green
means all authorization objects are fully maintained (no open fields). Yellow means some fields
have organizational level values that need to be maintained. Red means critical fields are
unmaintained or there are open authorization checks. Always aim for green before transporting a
role to Production.

Q27: What is an Organizational Level in SAP authorization?

Answer: Organizational levels are special authorization fields that represent business unit
structures — such as Company Code, Plant, Sales Organization, Controlling Area. They are
defined in SU24 and maintained separately from other fields in PFCG. In derived roles, the parent
defines the structure while each child role has different org-level values, enabling role reuse across
different parts of the organization.

Q28: What is the SAP_ALL and SAP_NEW profile and when is their use permitted?

Page 6 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

Answer: SAP_ALL grants unrestricted access to all objects and transactions. SAP_NEW
temporarily grants access to all new authorization objects added in a new SAP release until roles
are updated. SAP_ALL should NEVER be used in Production — it bypasses all SoD controls.
SAP_NEW should only be temporarily assigned during upgrades and promptly removed once roles
are properly updated.

Q29: How do you perform a role comparison in PFCG?

Answer: Use the PFCG role comparison function or transaction SUPC. This compares the
authorization data in a role against the current SU24 proposals and flags missing or new
authorization checks. After SAP upgrades or support pack installations, run comparisons to ensure
roles include all new required authorization objects. This prevents authorization errors for users
after system updates.

Q30: What is the Mass Role Comparison and when is it needed?

Answer: Mass Role Comparison (transaction SUPC) compares all roles against updated SU24
proposals simultaneously — used after SAP upgrades, support packages, or enhancement pack
installations. New SAP functionality may introduce new authorization objects. Without comparison
and update, users may get authorization errors. SUPC shows which roles need update and allows
batch processing.

Q31: What is role buffering and why can it cause issues?

Answer: SAP buffers authorization data for performance. When a role is modified and a new profile
generated, users currently logged in may not immediately receive the new authorizations. They
must log out and log back in to refresh their buffer. This can cause confusion when a security
change appears not to work — always instruct affected users to re-login after authorization
changes.

Q32: How do you handle authorization errors for a new transaction added to production?
Answer: 1) Identify the missing authorization using SU53 or SM20. 2) Check SU24 proposals for
that transaction. 3) In PFCG (Dev system), add the transaction to the appropriate role and maintain
missing auth objects. 4) Generate profile, test in QA. 5) Transport to Production. 6) Ask user to re-
login. Never make direct role changes in Production — always follow the transport process.

Q33: What is the difference between hard-coded and soft-coded authorization checks?
Answer: Hard-coded checks are written directly in ABAP code using AUTHORITY-CHECK
statements — they always run regardless of SU24 settings. Soft-coded checks use the proposal
values from SU24 and can be influenced via PFCG. Hard-coded checks cannot be turned off.
Understanding which type of check failed is important for troubleshooting authorization errors
accurately.

Q34: What is the user menu vs. SAP menu in PFCG?

Answer: The SAP Menu is the complete standard SAP menu with all transactions. The User Menu
is the customized subset of transactions added to a role in PFCG, which appears in the user's Easy
Access menu. Best practice is to give users a clean, task-focused user menu rather than exposing
the entire SAP menu — this reduces confusion and improves security by not revealing transactions
the user cannot access anyway.

Q35: How would you manage roles during an SAP upgrade?

Answer: 1) Before upgrade: document all existing roles and run a baseline authorization report. 2)
In Dev: apply upgrade and run mass role comparison (SUPC). 3) Update roles with new
authorization objects and maintain new field values. 4) Test all critical business processes in QA
with updated roles. 5) Transport updated roles to Production during upgrade window. 6) Monitor
post-upgrade for auth errors and address promptly.

Page 7 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

Page 8 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

IV. Authorization Objects & Troubleshooting

Q36: What is an Authorization Object?
Answer: An Authorization Object is a security check that SAP performs during a transaction or
program. It consists of up to 10 fields, each with specific permissible values. Common examples:
S_TCODE (transaction code access), F_BKPF_BUK (FI document company code),
M_MSEG_BWA (goods movement type). When a user runs a transaction, SAP checks if their
profile contains the required authorization object with matching field values.

Q37: What is SU53 and how do you use it for troubleshooting?

Answer: SU53 displays the LAST failed authorization check for a user. After a user gets an
'authorization error', they run SU53 (/nSU53) or an admin runs it via SU53 → Display Other User. It
shows the missing authorization object, field names, and the specific values that were checked but
not found in the user's profile. This is the primary first-step diagnostic tool for authorization errors.

Q38: What is the limitation of SU53?

Answer: SU53 only shows the LAST failed authorization check. If a user encountered multiple
authorization errors, only the most recent one is shown. Also, SU53 does not show successful
checks — only failures. Additionally, if the user navigated away or performed other actions after the
error, the relevant check may be overwritten. In such cases, use SM20 (Security Audit Log) for a
complete history.

Q39: How do you use ST01 for authorization tracing?

Answer: ST01 (System Trace) records all authorization checks (successful and failed) during a
transaction. Process: 1) Activate trace in ST01 for the specific user and component 'Authorization
check'. 2) User reproduces the issue. 3) Deactivate trace. 4) Analyze results to see all checks
performed — which passed and which failed. ST01 gives a complete picture unlike SU53, but
generates large volumes of data.

Q40: What is authorization object S_TCODE and why is it important?

Answer: S_TCODE checks whether a user is allowed to execute a specific transaction code. Field:
TCD (transaction code). When a user runs any transaction, SAP first checks S_TCODE. If this
check fails, the user sees 'You are not authorized to use transaction XXXX'. It is one of the most
fundamental authorization objects. Access to S_TCODE with * (all transactions) is extremely
critical.

Q41: Explain the authorization object S_DEVELOP and its risks.

Answer: S_DEVELOP controls access to ABAP Workbench activities — creating/modifying
programs, function modules, classes, etc. Field ACTVT 01/02 with object type '*' effectively gives
ability to write or modify code. This is extremely critical in Production — no developer should have
S_DEVELOP with change access in Production. Access to the ABAP editor in Production is a major
audit finding.

Q42: What is USOBX / USOBT and how do they relate to SU24?

Answer: USOBT stores the SU24 check indicators and default field values for authorization objects
per transaction. USOBX stores whether the check is set to Check, Do Not Check, or Check and
Propose. SU24 provides a maintenance interface for these tables. When building roles in PFCG,
the system reads SU24 proposals to suggest which authorization objects should be included and
with what default values.

Q43: What is an authorization check in background programs (batch jobs)?

Page 9 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

Answer: Background jobs run under a specific user ID. The user running the batch job must have
all necessary authorizations for the activities performed in the program, PLUS the additional
authorization S_BTCH_JOB (submit background jobs) and S_BTCH_ADM for job administration.
Using system users (type B) for batch ensures they can't be used for dialog logon while still having
required processing authorizations.

Q44: What is the authorization object P_ORGIN and when is it used?

Answer: P_ORGIN is used in HR (Human Resources) module to control access to HR master
data. It includes fields for: INFTY (infotype number), SUBTY (subtype), AUTHC (authorization level:
read/write/etc.), PERSA (personnel area), PERSG (employee group), PERSK (employee
subgroup), and VDSK1 (organizational key). HR security is often handled separately from other
modules due to data sensitivity.

Q45: How do you grant access to specific fields within a report in SAP?
Answer: Field-level security in SAP reports is typically controlled through authorization objects
specific to that module (e.g., restricting which company codes or plants a user can see). For custom
reports, developers should implement AUTHORITY-CHECK statements for relevant objects.
Additionally, tools like Analysis Authorization (for BW/BEx) provide field and record-level access
control for analytical applications.

Q46: What is a missing authorization versus an incorrect authorization?

Answer: A missing authorization means the required authorization object or value is completely
absent from the user's profile — SU53 clearly shows the failed check. An incorrect authorization
means the object exists but with wrong field values (e.g., user has company code 1000 but tries to
access 2000). Both appear as authorization errors but have different fixes: add the object or extend
the existing field values.

Q47: What is the purpose of the authorization object S_USER_AGR?

Answer: S_USER_AGR controls who can maintain role assignments and which roles they can
assign. Key fields: ACT_GROUP (the role name or pattern), ACTVT (activity: 22=assign,
70=manage role assignments). This object is critical for preventing privilege escalation — without
proper restrictions, a security admin could assign themselves or others to any role including
powerful ones like SAP_ALL.

Q48: How do you troubleshoot an authorization error in a workflow?

Answer: Workflow authorization issues involve both SAP Basis/Security and the workflow
configuration. Steps: 1) Identify the work item and agent. 2) Check that the workflow user (typically
WF-BATCH) has correct authorizations in SWI5/SWIA. 3) Review the workflow task for required
authorization checks. 4) Use SU53 while reproducing the error in the workflow context. 5) Check
SWEL (workflow event log) for system errors during workflow execution.

Q49: What is segregation at the authorization object field level?

Answer: This means restricting specific field VALUES within an authorization object rather than the
entire object. Example: A user has F_BKPF_BUK for posting documents, but only for company
codes 1000 and 2000, not 3000. Another user has the same object but only for 3000. This field-
level restriction creates fine-grained access control and enables proper SoD — same transaction,
different data scope.

Q50: What happens when you run SU25?

Answer: SU25 is the SU24 data upgrade tool. It compares the customer SU24 settings against the
latest SAP-delivered SU24 data (after upgrades/support packs) and helps synchronize them. It
offers options to: copy new SAP proposals to customer namespace, compare differences, reset to

Page 10 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

SAP defaults, or selectively update. Running SU25 after upgrades ensures role proposals are
current, preventing authorization gaps for new functionality.

Page 11 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

V. SAP GRC & Compliance

Q51: What is SAP GRC Access Control and what are its key modules?
Answer: SAP GRC Access Control manages access risk across SAP and non-SAP systems. Key
components: ARA (Access Risk Analysis) — detects SoD conflicts; ARM (Access Request
Management) — workflow-based provisioning; EAM (Emergency Access Management / Firefighter)
— controlled superuser access; BRM (Business Role Management) — role design and lifecycle;
UARR (User Access Review and Reporting) — periodic recertification.

Q52: What is a Ruleset in GRC Access Control?

Answer: A Ruleset defines which combinations of SAP access constitute SoD conflicts. It contains:
risk definitions (named conflicts like 'AP01: Create and Pay Vendor'), functions (groups of
authorizations that represent a business capability), and risk levels (critical, high, medium, low).
SAP provides a standard ruleset and organizations customize it to reflect their control requirements.
Rulesets are used by ARA to analyze user access.

Q53: What is the difference between a SoD Risk and a Critical Action in GRC?
Answer: A SoD Risk involves two or more conflicting functions that together create a risk (e.g., one
function creates vendors, another pays vendors — having both enables fraud). A Critical Action (or
Critical Object) is a single action that is risky on its own regardless of other access (e.g., deleting all
production orders, running payroll, changing system configuration). Both require mitigation controls.

Q54: What is a Mitigation Control in GRC?

Answer: A Mitigation Control is a compensating control that reduces the risk of an SoD conflict that
cannot be resolved by removing access. Examples: manager review of vendor payments, audit
reports reviewed monthly, transaction logs monitored by internal audit. In GRC, mitigations are
documented, assigned to users, and given validity periods. Mitigated risks are flagged separately in
compliance reports, showing the residual risk is accepted and controlled.

Q55: What is the Firefighter (Emergency Access Management) process?

Answer: Firefighter provides time-limited emergency access: 1) A business user requests
firefighter access through GRC. 2) The Firefighter ID Owner approves. 3) The user logs in using the
firefighter ID. 4) All actions are logged comprehensively (transactions run, changes made). 5) After
the session, a log report is automatically emailed to the ID Owner and Controller. 6) The Controller
reviews and approves/rejects the activity. It maintains audit trail for emergency superuser access.

Q56: What is Access Request Management (ARM) in GRC?

Answer: ARM provides a formal workflow for requesting, approving, and provisioning SAP access.
Process: 1) User or manager submits access request. 2) Request undergoes SoD analysis —
conflicts flagged. 3) Role owner approves business justification. 4) Security team provisions access.
5) All steps are documented. ARM replaces informal access granting with an auditable, controlled
process meeting SOX and audit requirements.

Q57: How does GRC integrate with SAP to check for SoD?
Answer: GRC connects to SAP systems via RFC connections. It extracts user master data, role
assignments, and authorization data into the GRC repository. The ARA engine then analyzes this
data against the configured ruleset. Real-time analysis can check a role or user before provisioning
(preventive). Batch analysis reports on existing access (detective). Results feed into compliance
dashboards and remediation workflows.

Q58: What is User Access Review (UAR) / Recertification?

Page 12 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

Answer: UAR is a periodic process (quarterly/annually) where business managers or role owners
review and certify whether their users still need current access. GRC automates this: sends review
tasks to managers, tracks responses, escalates overdue reviews, and automatically removes
access that is not recertified. UAR is a key SOX and audit control demonstrating that access is
regularly reviewed and unnecessary access is removed.

Q59: What is the difference between preventive and detective controls in GRC?
Answer: Preventive controls stop a risk from occurring — e.g., GRC blocks an access request that
would create an SoD conflict before provisioning. Detective controls identify risks after they exist —
e.g., batch SoD analysis reports showing existing violations in user access. Best practice combines
both: prevent new violations at provisioning time and regularly detect any that exist through periodic
analysis.

Q60: How would you reduce SoD violations in an organization?

Answer: 1) Implement proper role design — task-based roles that inherently avoid SoD. 2) Use
GRC ARM for all access requests with SoD analysis. 3) Conduct User Access Reviews and remove
unnecessary access. 4) Work with business to redesign job functions where possible. 5) Where
conflicts cannot be eliminated, implement and document compensating controls. 6) Regularly report
metrics to management to drive remediation accountability.

Q61: What is SAP Process Control and how does it differ from Access Control?
Answer: SAP Process Control focuses on monitoring business process controls — automated
checks on transactional data (e.g., detecting duplicate vendor invoices, verifying approval
thresholds). Access Control focuses on who has access to what. Process Control detects control
failures in what users actually DO, while Access Control manages what they are ALLOWED to do.
Together they provide a comprehensive compliance framework.

Q62: What is SOX compliance and how does SAP Security support it?
Answer: SOX (Sarbanes-Oxley Act) requires public companies to maintain strong internal controls
over financial reporting. SAP Security supports SOX by: implementing SoD controls over financial
transactions, maintaining audit logs (SM20) of user activities, ensuring proper change management
(no direct Production changes), conducting User Access Reviews, and providing evidence of
controlled access through GRC reporting and documentation.

Q63: What is a Critical Authorization in SAP from a compliance perspective?

Answer: Critical authorizations are access rights that pose significant risk if misused or given to
wrong users. Examples: SA38/SE38 (run/edit ABAP programs), SCC4 (client settings), SE16 (direct
table access without authorization checks), SM59 (RFC destinations), SU01 (user admin), PFCG
(role maintenance). These should be assigned to as few users as possible, require special
approval, and be regularly audited.

Q64: What is SE16N and why is access to it critical?

Answer: SE16N is an enhanced table browser that allows direct read access to database tables.
Unlike SE16, it has some authorization capabilities, but access to it should still be restricted. The
concern: users could bypass application logic and read sensitive data (HR, financial records,
customer data) directly from tables. The authorization object S_TABU_DIS/S_TABU_NAM controls
table access. In Production, SE16N access should be limited to authorized admins only.

Q65: What is a Security Baseline in SAP?

Answer: A Security Baseline is a documented set of minimum security standards for SAP systems.
It includes: required system parameters (login policies, password rules), user administration
standards (no shared accounts, regular review), roles and authorization standards (least privilege,
SoD controls), audit logging requirements, network security measures, and compliance with

Page 13 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

regulations. Baselines are used to assess security posture against known best practices like SAP
Security Optimization Service recommendations.

Page 14 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

VI. Audit, Monitoring & Advanced Topics

Q66: What is the Security Audit Log (SM19/SM20) and what should be monitored?
Answer: The Security Audit Log records security-relevant events. SM19 configures what to log
(user, client, event types). SM20 reviews the log. Key events to monitor: failed logon attempts,
successful logon with critical users (SAP*, DDIC), transaction starts for critical transactions, report
starts, RFC calls, user master changes, authorization failures for sensitive objects. Logs should be
reviewed regularly and archived for compliance.

Q67: What is the SAP System Log (SM21) and how is it used in security?
Answer: SM21 is the System Log recording system-level events including failed logon attempts,
system errors, and abnormal program terminations. From a security perspective, monitor for:
repeated failed logons (potential brute force), logons by unexpected users, system errors that might
indicate an attack, and RFC connection failures. SM21 complements SM20 by providing system-
level rather than application-level security events.

Q68: What is transaction SUIM and its key reports?

Answer: SUIM is the User Information System — a reporting hub for security analysis. Key reports:
Users by authorization values (who has access to a transaction/object), Roles by authorization
(which roles contain a specific auth object), Users with SAP_ALL or SAP_NEW, Users who have
not logged on in X days, Users with critical authorizations, Roles not yet assigned to any user.
SUIM is essential for regular security monitoring and audit evidence.

Q69: What is authorization audit trail and how do you provide evidence for auditors?
Answer: Auditors require evidence that: only authorized users have access, access was properly
approved, SoD controls are in place, and access is regularly reviewed. Evidence includes: GRC
ARM request logs (who approved what access and when), SUIM reports (who currently has
access), SM20/SM19 audit logs (security events), UAR completion records (access was reviewed),
and role documentation (what business purpose each role serves).

Q70: What is SAP Note and how does it relate to security patching?
Answer: SAP Notes are corrections and enhancements released by SAP, including security
patches. Security-related Notes (often from SAP Security Patch Tuesday) fix vulnerabilities in SAP
software. The process: SAP releases note, security team reviews impact, note is applied in Dev,
tested, then transported to Production. Keeping systems patched is critical. SAP releases security
notes on the second Tuesday of each month. Transaction SNOTE applies notes.

Q71: What is the concept of 'least privilege' in SAP security?

Answer: Least privilege means users should have only the minimum access required to perform
their job functions — nothing more. In SAP: build task-specific roles rather than broad roles, avoid
giving access to entire modules when only specific transactions are needed, restrict organizational
levels to relevant units only, regularly review and remove access that is no longer needed, and
never assign SAP_ALL or similar profiles. It minimizes the damage potential from compromised
accounts.

Q72: What is SAP Identity Management (IDM) and how does it integrate with security?
Answer: SAP Identity Management provides centralized management of user identities and access
across SAP and non-SAP systems. It automates: user provisioning/deprovisioning triggered by HR
events (joiner/mover/leaver), access request workflows, role assignments based on job positions,
and access recertification. IDM integrates with GRC for SoD checks and with HR for identity
lifecycle management, reducing manual security administration effort.

Page 15 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

Q73: What is Audit Information System (AIS) in SAP?

Answer: AIS (transaction SECR or via CATT) provides structured audit tools for both system audits
and business audits. Security-relevant audit workbooks include: User Administration Audit,
Authorizations Audit, System Configuration Audit, and Change Document Audit. AIS organizes
relevant reports and transactions into logical groups making it easier for internal/external auditors to
assess SAP security controls systematically.

Q74: How do you handle authorization for custom ABAP programs?

Answer: For custom programs: 1) Work with developers to identify what data is accessed and what
business risk exists. 2) Identify existing authorization objects that cover this data, or design custom
authorization objects if needed (SE11/SU20). 3) Ensure developers implement AUTHORITY-
CHECK in the code. 4) Maintain SU24 proposals for the custom transaction. 5) Include required
authorization objects in appropriate roles. 6) Test with a test user who has minimal access to verify
checks work.

Q75: What is the difference between authorization and data privacy (GDPR) in SAP?
Answer: Authorization controls WHO can access WHAT functionality/data in SAP. GDPR (General
Data Protection Regulation) addresses how personal data is collected, processed, stored, and
deleted. In SAP, both work together: authorization prevents unauthorized access to personal data
(security measure), while GDPR requires proper data governance, consent management, and right-
to-be-forgotten capabilities. SAP S/4HANA includes Information Lifecycle Management (ILM) and
Data Privacy tools to support GDPR compliance.

Q76: What is the concept of Role Mining in SAP security?

Answer: Role Mining is the process of analyzing existing user access patterns to derive role
definitions from actual usage rather than theoretical job descriptions. Tools (including SAP GRC)
analyze historical authorization data to identify natural clusters of users with similar access. This
helps rationalize existing bloated role landscapes, identify over-provisioned access, and build a
clean role library aligned with actual business needs. Common in large remediation projects.

Q77: What is the ABAP test cockpit and how does it relate to security?
Answer: The ABAP Test Cockpit (ATC) includes security checks that identify authorization
vulnerabilities in custom ABAP code — such as missing AUTHORITY-CHECK statements,
hardcoded passwords or user names, SQL injection vulnerabilities, and use of obsolete/insecure
function modules. Running ATC checks as part of development quality gates ensures security
issues are caught before code reaches Production.

Q78: What are the security implications of SAP Solution Manager?

Answer: SAP Solution Manager has extensive connections to all managed SAP systems (via RFC,
SMDAgent). Security risks: Solution Manager itself must be well-secured since compromise could
affect all connected systems, RFC connections must be properly restricted, the Early Watch Alert
and other monitoring features must use system users with minimum necessary access. Misuse of
Solution Manager access can potentially impact entire SAP landscapes.

Q79: What is SNC and how is it configured?

Answer: SNC (Secure Network Communications) encrypts SAP network communications using
external security products (Kerberos, NTLM, etc.). Configuration: 1) Install SNC library on
application server. 2) Set profile parameters (snc/enable, snc/gssapi_lib, snc/identity/as). 3)
Configure SNC names for users in SU01 (SNC field). 4) Enable SNC for RFC connections in SM59.
5) Enable for SAP GUI connections. SNC prevents eavesdropping on SAP communications and
enables SSO.

Q80: What is Privilege Access Management (PAM) and how does SAP GRC EAM fit?

Page 16 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

Answer: PAM is the discipline of controlling, monitoring, and auditing access by privileged users
(admins, superusers). SAP GRC EAM (Firefighter) is SAP's PAM solution for emergency/privileged
access: it enforces time-limited access, comprehensive logging of all actions by privileged users,
and automatic review workflows. This ensures that even necessary emergency superuser access is
controlled, documented, and reviewed — meeting audit requirements for privileged access control.

Page 17 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

VII. S/4HANA, Cloud & Modern SAP Security

Q81: How does SAP S/4HANA security differ from ECC security?
Answer: S/4HANA introduces several security differences: Fiori apps use OData services requiring
additional backend authorization objects and frontend Fiori catalog/group assignments. Business
role concept in Fiori launchpad complements traditional PFCG roles. HANA database has its own
security layer (HANA users/roles). New authorization objects specific to S/4HANA functionality.
Some ECC SoD risks change with simplified processes. Overall, S/4HANA security requires
managing both classic ABAP layer and new Fiori/HANA layers.

Q82: What is SAP Fiori security and how are Fiori authorizations managed?
Answer: Fiori security has two layers: 1) Fiori Frontend (Launchpad): App Catalogs and Groups
are assigned via Business Roles in the Fiori Launchpad designer — these control which tiles/apps
users see. 2) Backend ABAP: Traditional PFCG roles with ABAP authorization objects control what
users can actually DO in the app. Both layers must be configured: frontend access to see the app +
backend authorization to use it. Missing either layer results in access issues.

Q83: What is SAP HANA database security?

Answer: HANA has its own security layer independent of ABAP. Key concepts: HANA users and
roles (created in HANA Studio or HANA Cockpit), privileges (system privileges, object privileges,
analytic privileges), row-level security via SQL views and analytic privileges, and audit logging.
ABAP system users connecting to HANA should have minimum privileges. Direct HANA access
should be strictly controlled — users with HANA access can bypass ABAP-layer authorization
controls.

Q84: What is SAP Cloud Identity Services and how is it used?

Answer: SAP Cloud Identity Services (formerly SAP Cloud Platform Identity Authentication / IAS)
provides identity management for SAP cloud solutions. It handles: single sign-on (SSO) via SAML
2.0/OAuth for cloud apps, user provisioning to cloud systems, multi-factor authentication (MFA),
and identity federation with corporate identity providers (Azure AD, LDAP). It is the central identity
hub connecting on-premise SAP systems with cloud solutions like SuccessFactors, Ariba, and
S/4HANA Cloud.

Q85: What are the security considerations for SAP BTP (Business Technology Platform)?
Answer: BTP security involves: Role collections (instead of traditional roles) assigned to users or
groups. Trust configuration connecting BTP to corporate identity providers. API security using
OAuth 2.0. Subaccount isolation for multi-tenant scenarios. Service instance credentials
management. Audit logging of BTP administrative activities. Security recommendations include: use
identity federation rather than local BTP users, enforce MFA, regularly review role collection
assignments, and monitor BTP audit logs.

Q86: What is Multi-Factor Authentication (MFA) in SAP context?

Answer: MFA requires users to provide additional authentication factors beyond
username/password — such as a mobile authenticator app (TOTP), SMS code, or hardware token.
In SAP: MFA can be implemented via SAP Cloud Identity Services (IAS), SAP Logon through
SNC+Kerberos with smart cards, or third-party solutions. MFA significantly reduces risk from
compromised passwords, especially for remote access and privileged user accounts. Increasingly
required for SOX and security compliance.

Q87: What is SAP Access Control on SAP BTP (Cloud GRC)?

Page 18 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

Answer: SAP Access Control is available as a cloud solution on SAP BTP. It provides the same
core GRC functionality (ARA, ARM, EAM, BRM) but as a SaaS offering. Benefits: lower
infrastructure maintenance, regular SAP updates, integration with cloud identity services, and
compatibility with both on-premise and cloud SAP systems. Organizations migrating to cloud need
to plan GRC landscape alongside S/4HANA Cloud adoption.

Q88: What is the SAP Security Optimization Service?

Answer: The SAP Security Optimization Service (formerly Security Service) is an SAP-provided
service that assesses the security configuration of SAP systems against SAP best practices and
recommendations. It evaluates: user administration settings, critical authorizations, system
parameters, transport security, RFC security, and more. The output is a detailed report with
recommendations and a security score. It is a good baseline for organizations to assess and
improve their SAP security posture.

Q89: What are SAP security recommendations for RFC connections?

Answer: Best practices for RFC security: avoid storing passwords in RFC destinations (use trusted
connections instead), regularly audit SM59 for unnecessary destinations, restrict S_RFC
authorization to specific function groups/modules needed, disable or secure RFC gateway
(parameter gw/sec_info and reginfo files), monitor RFC connections for unusual usage, and use
SNC to encrypt RFC communication. RFC is a common attack vector — attackers exploit trusted
RFC connections to escalate privileges.

Q90: What is the difference between SAP on-premise security and SAP Cloud security
models?
Answer: On-premise: full control over security configuration, traditional ABAP roles, managed by
customer's security team, infrastructure security responsibility lies with customer. Cloud (e.g.,
S/4HANA Cloud Public Edition): SAP manages infrastructure and baseline security, customer
manages user access and business role configuration, limited customization of authorization
objects, role templates provided by SAP, and identity management via IAS. Cloud requires trusting
SAP's platform security while maintaining oversight of user access governance.

Page 19 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

VIII. Scenario-Based & Behavioral Questions

Q91: Walk me through your approach to a full SoD remediation project.
Answer: 1) Scope: Identify systems in scope and agree on ruleset with business/audit. 2) Analyze:
Run GRC or manual SUIM analysis to identify all SoD violations. 3) Prioritize: Focus on Critical and
High risks first. 4) Remediate: For each conflict — determine if access can be removed, roles
redesigned, or if mitigation is needed. 5) Engage business: Work with managers to confirm which
access is truly needed. 6) Implement: Remove excess access, redesign roles, document
mitigations. 7) Re-analyze: Confirm violations are resolved. 8) Sustain: Implement preventive GRC
controls.

Q92: How do you handle a situation where a business user urgently needs access to a
critical transaction in Production?
Answer: 1) Never grant access directly in Production without following process. 2) Verify business
justification — is this truly urgent? 3) If SAP GRC Firefighter is available, provision a firefighter ID
for emergency access with full logging. 4) If no GRC, escalate to manager/security officer for formal
emergency approval — document everything. 5) Grant the minimum access needed via standard
transport if possible, or via emergency change procedure with dual approval. 6) Review and remove
temporary access after the need is resolved.

Q93: A user calls saying they cannot access a transaction they use every day. What do you
do?
Answer: 1) Ask the user to run /nSU53 and share the screenshot — this shows the missing
authorization. 2) Verify the user is assigned to the correct role (SU01 → Roles tab). 3) Check if the
role was recently changed or if a transport may have overwritten it. 4) Check if the user's role or
account validity has expired. 5) If a legitimate authorization gap is found, update the role in
Development and transport. 6) Ask the user to log out and back in to refresh the authorization
buffer. 7) Confirm resolution.

Q94: How would you conduct a security review for a new SAP system implementation?
Answer: 1) Define security requirements based on regulations (SOX, GDPR) and company policy.
2) Design role concept — task-based, SoD-aware roles aligned with job descriptions. 3) Configure
system security parameters (login policies, audit logging, SNC). 4) Implement GRC for access
request workflows and SoD monitoring. 5) Secure basis elements (RFC, background jobs,
interfaces). 6) Conduct penetration testing / vulnerability assessment. 7) Train administrators and
users on security procedures. 8) Document everything for audit readiness before go-live.

Q95: How do you stay current with SAP security threats and patches?
Answer: 1) Subscribe to SAP Security Notes — SAP releases patches on the second Tuesday of
each month (Patch Tuesday). 2) Follow SAP Security Response on SAP Support Portal. 3) Monitor
CVE databases for SAP-related vulnerabilities. 4) Join SAP security user groups (ASUG, DSAG). 5)
Follow security researchers who specialize in SAP (ERPScan, SAP-focused conference talks). 6)
Regularly check SAP Security Optimization Service recommendations. 7) Participate in internal
security reviews and external penetration tests.

Q96: What is your approach to documenting SAP security for auditors?

Answer: Maintain: 1) Role inventory — each role with its purpose, owner, and last review date. 2)
Access request records — who requested what, who approved, when provisioned. 3) User access
reviews — evidence of periodic recertification. 4) SoD reports — violations identified, remediated, or
mitigated with justification. 5) Change management records — all security changes went through
proper transport process. 6) System configuration documentation — login parameters, audit log

Page 20 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

settings. Organize everything to answer: who has access, how was it approved, is it still needed,
and what controls prevent misuse.

Q97: Describe a challenging SAP security problem you solved (or would solve).
Answer: A well-structured answer should include: Context (system, business, problem identified),
Challenge (SoD violation, emergency access gap, compliance finding, etc.), Analysis (how you
investigated — SUIM, SU53, GRC reports), Solution (role redesign, mitigation control, process
improvement), and Outcome (audit finding resolved, risk reduced, user productivity maintained).
Use the STAR method: Situation, Task, Action, Result. Even hypothetical scenarios should follow
this structure with technical specifics.

Q98: How do you balance security requirements with business productivity needs?
Answer: Security should enable business, not block it. Approach: 1) Understand the business
process deeply — what does the user actually need to do? 2) Apply least privilege — grant exactly
what's needed, no more. 3) Use time-limited or conditional access where appropriate. 4) Implement
Firefighter for emergency scenarios — don't permanently over-provision to avoid future
emergencies. 5) Educate users and managers on why controls exist. 6) Track and communicate
security metrics that show value. A security consultant who understands the business builds
sustainable security; one who only enforces rules builds workarounds.

Q99: How would you handle the discovery that a user has SAP_ALL in Production?
Answer: 1) Immediately assess risk — who is the user, what have they been doing? Review SM20
audit logs for recent activity. 2) Report immediately to management and security officer — this is a
critical finding. 3) Remove SAP_ALL promptly — document the removal with approval. 4)
Investigate why it was assigned — was it a break-glass scenario, unauthorized change, or
administrative error? 5) Assign proper roles for legitimate needs. 6) If unauthorized, treat as a
security incident — forensic review of user actions. 7) Improve controls to prevent recurrence —
GRC preventive controls, approval requirements for critical profile assignments.

Q100: Where do you see SAP Security evolving in the next 3-5 years?
Answer: Key trends: 1) Cloud-first security — as organizations move to S/4HANA Cloud and BTP,
security must evolve to manage cloud identity and API security. 2) Zero Trust Architecture — no
implicit trust, verify every access request. 3) AI/ML in security monitoring — automated anomaly
detection in user behavior (SAP Enterprise Threat Detection). 4) Continuous compliance — real-
time monitoring replacing periodic reviews. 5) Identity-centric security — stronger integration with
enterprise IAM/PAM. 6) Privacy-by-design — GDPR and data privacy embedded in SAP processes.
Staying relevant requires continuous learning and adapting beyond traditional PFCG role
maintenance.

Page 21 of 22
SAP Security Consultant — Interview Preparation Guide | Top 100 Real-Time Q&A

Interview Success Tips

✦ Know Your Tools Cold: Be fluent in PFCG, SU01, SU53, SM20, SUIM, SM59. Practice navigating
these in a sandbox system if possible.
✦ Link Security to Business Value: Frame answers in terms of business risk, compliance, and
enabling the business — not just technical process.
✦ Understand SoD Deeply: SoD is central to SAP security. Know examples from FI (Procure-to-Pay,
Order-to-Cash) and explain mitigating controls.
✦ GRC Experience is Gold: Even basic GRC knowledge (ARA, ARM, EAM) significantly improves
your candidacy. Highlight any GRC project experience.
✦ Be Ready for Scenarios: Interviewers love 'what would you do if...' questions. Practice the SU53
troubleshooting flow, emergency access process, and audit evidence gathering.
✦ Know S/4HANA Differences: Modern SAP landscapes are S/4HANA. Know Fiori security, HANA
DB security basics, and how they differ from ECC.
✦ Quantify Your Impact: Use numbers: 'Reduced SoD violations by 60%', 'Completed 500-user
access review in 2 weeks', 'Implemented GRC for 8 systems'.
✦ Ask Smart Questions: Ask about the security maturity of their landscape, any current GRC
initiatives, or plans for S/4HANA migration — it shows strategic thinking.

Good Luck with Your Interview! You've Got This.

Page 22 of 22