SAP security interview questions

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 10 October 2026 · facts checked against SAP Learning and the SAP Help Portal, October 2026

SAP security interview questions test whether you can decide what a user may do, build it, and defend it to an auditor: reading a failed authorisation check, sizing roles, segregation of duties, the user lifecycle and emergency access, the boundary with Basis, and the audit walkthrough. Each block gives the scenario and the answer that survives the follow-up.

What does a security interview cover?

Three people usually want different things from the same answer: a process owner who wants access granted today, an auditor who wants it justified next quarter, and an administrator who wants nobody near the system parameters. A security and authorisations consultant answers to all three, and the interview will test you as each of them in turn. An in-house team asks about the concept it already has and the audit findings it remembers; an integrator asks how you would write a concept from nothing and land it before testing; a regulated industry asks about controls first and roles second. Unlike a functional interview there is rarely a business process to design; there is almost always a failed check to read and a role to size.

Most security questions end at a screen an auditor would also ask to see, so the panel listens for which one you would open. The table sets each theme beside what it tests and the objects a strong answer names.

How is the failed-check question asked?

"A user cannot post a document she posted yesterday. Go." The bad answer is to add a wide profile and see. The good answer is a sequence: reproduce, read the failed check back to the authorisation object and the field value that blocked it, find out what changed — a role regenerated, an organisational level added, a transport that overwrote a derived role — and fix the cause in the role rather than the symptom on the user. Follow-ups test the mechanism: what the trace shows that the failed-check display does not, why a role can look right and still fail, what a missing organisational value does. Interviewers also ask what you do when the fix is urgent and the proper one takes a day, because the answer — a documented temporary grant with an end date — is the habit they are hiring for.

Which role-design scenarios get tested?

"Design the access for a purchasing department across three plants where buyers may only see their own plant." This is the scenario that exposes whether you know what single, composite and derived roles are each for, and how organisational levels let one master role become many without copying. Say the mechanism: a derived role inherits the menu and the authorisations of its master and may differ only in organisational levels, so a change is made once in the master and pushed to the derived roles from PFCG. Good answers explain the trade-off at the centre of the job: a role built per task is precise and produces hundreds; a role built per position is manageable and grants too much; the craft is the middle, and the concept document is where the middle is written down. Follow-ups turn the screw: a rollout adds a country and the roles must repeat, a reorganisation merges two plants, an auditor asks why a display role contains a change activity. The people who have lived through a role redesign describe the naming convention first, because they know what happens without one.

How does segregation of duties come up?

As a conflict to resolve rather than a rule to recite. "The finance manager needs to create suppliers and run the payment run. What do you do?" The interviewer wants three things: recognition that this is a classic conflict, a description of how a ruleset finds it — actions in combination, at the level of the authorisation objects rather than the transaction names — and a decision: split the access, or accept the conflict with a mitigating control that someone reviews. Know the four parts of SAP Access Control by name: access risk analysis, access request management, business role management and emergency access management. As of October 2026 release 12.0 is in mainstream maintenance to the end of 2027, so expect to be asked what you would move to. That is where security meets the GRC area, and interviewers in regulated industries will ask how the risk analysis is run before a role is assigned rather than after an audit finds it. Answers that mention the small company where one person does everything, and how you document that honestly, sound like experience.

What do user lifecycle and emergency access questions look for?

Joiners, movers and leavers is the frame, and the mover is the case that separates candidates: a person who changes department keeps the old access unless a process removes it, and most conflicts an auditor finds were created that way. Expect questions on how access requests are approved and by whom, how a leaver's access ends on the day, and how periodic reviews are run so that they are read rather than rubber-stamped. Emergency access is its own question: how a firefighter identity is granted for a defined window, logged in a way someone actually reviews, and closed — and what you would say when the programme asks for wide access to stay open "until hypercare ends". The public cloud edition adds one more: there is no PFCG, only business roles assembled from SAP's business catalogues with restrictions in the Maintain Business Roles app, and identity comes from SAP Cloud Identity Services. Interviewers like to hear which of your habits would change.

Which Fiori and S/4HANA authorisation questions come up?

"The tile is missing" and "the app opens but shows nothing" are two different faults, and the interviewer wants them taken apart. A missing tile is a launchpad problem: the user's role does not contain the business catalogue that holds the app, or the space and page were never assigned. An app that opens and then fails is an authorisation problem in two layers. The start authorisation for the app's OData service is the object S_SERVICE, which PFCG generates when the catalogue or the service is added to the role menu. Behind it sit the business authorisations, the same objects the old transaction checked, proposed through SU24 for the service. The tools are unchanged: SU53 and STAUTHTRACE, run on the system where the service executes. Add that the SAP Fiori apps reference library lists the catalogue and the services for each standard app, because that is where the role build starts.

Which short technical questions are still asked?

The ones that show whether you have run the tools or only read about them. Each has a one-line answer, and the follow-up is always when you last needed it.

Where does the boundary with Basis get tested?

An auditor's standing objection is that an administrator holding unrestricted access to a system can quietly widen their own, which is why the two jobs are held apart wherever headcount allows. The interview checks that you can say where that line falls when you look at it from the security side, as the Basis interview checks it from the other. Expect questions on who owns the powerful standard users, the connections between systems and the identities they run under, the parameters that govern passwords and logins (for example login/min_password_lng and login/fails_to_user_lock, or a security policy in SECPOL), and the audit log, configured in RSAU_CONFIG and read in RSAU_READ_LOG on current releases. Expect one more on what you do when a Basis colleague asks for a security role to speed up a migration weekend. The good answer separates the system-level controls, which Basis operates and security reviews, from the business access, which security designs and Basis must not grant.

What does the audit walkthrough look like?

Somewhere in the interview you become the person the auditor is talking to. "Who can release a payment above the limit, and show me." What is scored is whether you answer from the system — the users, the roles that grant it, the object and field behind it, the review that last confirmed it — rather than from memory, and whether you can say calmly what the finding would be if the answer were wrong. Interviewers also ask what evidence you keep between audits, because a concept nobody maintains is the first thing an auditor finds. Candidates who have sat through a finding, and can describe the remediation and the retest, are the ones an in-house team wants beside them next time.

What should a security candidate rehearse?

• One failed check, narrated from trace to the fix in the role.
• One concept you wrote or inherited: naming, role model, and what you would redesign. The authorisations consultant guide describes the day-to-day work those stories come from.
• The classic finance and procurement conflicts, with the mitigating control you would accept and the one you would refuse; the GRC guide covers the tooling.
• A view on the public cloud edition, where roles are built from business catalogues and identity is central.