SAP security interview questions

An SAP security interview tests whether you can decide what a user may do, build it, and defend it to an auditor. The questions cover reading a failed authorisation check, designing roles that are wide enough to work with and narrow enough to defend, segregation of duties, the user lifecycle with its emergency access, the boundary with Basis, and the audit walkthrough. This guide takes each block with the questions it produces and what a good answer shows.

What does a security interview cover?

The security and authorisations role sits between the business that asks for access, the auditors who challenge it and the technical team that runs the system, and the interview visits all three neighbours. 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.

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. 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. 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 cloud editions add one more: roles built from business catalogues and identity supplied by a central service change the habits, and interviewers like to hear that you know which of yours would change.

Where does the boundary with Basis get tested?

The person who can change the system should not also decide who may use it, and the interview checks that you understand the boundary 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, and the audit log — and 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 — the trace, the object, the field, the cause, the fix in the role — as you actually did it.
• One concept you wrote or inherited: the naming convention, the role model, and what you would redesign.
• The classic conflicts in finance and procurement, with the mitigating control you would accept and the one you would refuse.
• A view on the cloud editions and what changes in your own habits when roles are catalogues and identity is central.
• The general pattern in the umbrella interview guide — walkthrough, changed fact, scars, translation — and the fact that in security the translation is to an auditor, who does not want to be reassured, only shown.