Why SAP access reviews matter
For a US-listed company, SAP is usually the core of internal control over financial reporting. Regulation S-K Item 308 requires management’s annual ICFR report, bars an “effective” conclusion if a material weakness exists, and requires auditor attestation for accelerated and large accelerated filers. The SEC’s 2007 management guidance, as summarized by Cooley, notes that automated controls “often depend upon effective IT general controls.”
Access is one of those IT general controls. If the wrong people can post journal entries, change vendor bank details or approve their own purchase orders, auditors cannot rely on SAP’s automated controls. Periodic access reviews are how companies show those risks are managed. In regulated life sciences, the same reviews also support data integrity expectations such as the access limits in 21 CFR 11.10.
Three periodic reviews in SAP Access Control
SAP’s training material describes three workflow-driven periodic reviews in SAP Access Control (often called SAP GRC Access Control):
| Review | Who reviews | Question answered |
|---|---|---|
| User Access Review (UAR) | Business managers (by user) or role owners (by role) | Is each user–role assignment still needed? |
| SoD Review | Managers or risk owners | Is access that creates a segregation-of-duties risk still justified? |
| Firefighter ID Review | Firefighter ID owners | Should each user keep access to emergency (firefighter) IDs? |
How the user access review workflow runs
- Data generation. An administrator schedules a background job defining the UAR type, target system, user scope and whether to exclude locked or expired users. It can recur.
- Request review (optional). Administrators check reviewer and coordinator assignments, reassign or cancel requests.
- Workflow update. A job moves requests into reviewers’ Work Inbox.
- Review. Reviewers approve, remove or forward each assignment, or reject a user they are no longer responsible for.
- Removal. Roles marked for removal are deleted in the target system, optionally after another approval stage.
- Rejections and reporting. Rejected users are regenerated to the right reviewer; the UAR History Report records decisions per role.
Coordinators track whether reviewers finish on time. Manager data can come from HR systems and role-owner data from Business Role Management, so the quality of the review depends on the quality of that master data.
SoD review
The SoD review follows the same pattern but presents only users with access risks from the rule set. The reviewer decides whether the conflicting access is still needed. A conflict that must stay should be linked to a documented mitigating control, otherwise the review only records the risk.
Firefighter log review
Emergency access is the highest-risk access in SAP. According to SAP’s emergency access training, Access Control collects up to five log types from the target system (transaction, change, system, security audit and OS command logs), shows them in a Consolidated Log Report with old and new field values, and routes a log review request to the firefighter controller. The controller can ask the firefighter for more information, forward the review, and signs off with “Submit and Close.” The system can only collect logs the target system is configured to capture, so log settings are part of the control.
User access review for SAP SuccessFactors
The fastest-growing query in this cluster is about SuccessFactors. Access there is driven by role-based permissions: permission roles assigned to a granted population, sometimes over a target population. SAP notes that RBP is “designed so that users will match more than one role,” so a meaningful review must look at the combined effect of layered roles and the size of target populations, not only at role names. Because SuccessFactors holds personal and compensation data, reviews also support privacy obligations.
The identity landscape is changing
SAP Identity Management 8.0 reaches the end of mainstream maintenance in 2027, with extended maintenance to 2030, according to SAPinsider (June 2026). Companies replacing it are redesigning provisioning and governance at the same time as many move to S/4HANA. Every one of those changes affects the populations, roles and evidence that access reviews rely on, so plan review evidence for the transition period explicitly.
What auditors look for in access review evidence
- Completeness: the user population in the review matches the system at the review date.
- Precision: reviewers saw roles with meaningful descriptions, not just technical names.
- Timeliness: reviews were completed within the defined window.
- Follow-through: every “remove” decision was actually removed in the system, with evidence.
- Reviewer independence: no one reviewed their own access.
- Mitigation: retained SoD conflicts map to operating mitigating controls.
- Firefighter logs: every session has a reviewed, signed-off log.
Common weaknesses
- “Rubber-stamp” approvals with hundreds of assignments approved in seconds.
- Reviews based on stale manager data, so departed managers or wrong reviewers receive requests.
- Removals approved in GRC but not provisioned, or re-granted soon after.
- SoD conflicts accepted without a mitigating control owner.
- Firefighter logs incomplete because security audit logging was not enabled in the target system.
- Cloud applications such as SuccessFactors left outside the review program.
Checklist: SAP access review readiness
- Review scope covers all SOX-relevant SAP systems and cloud apps
- Manager and role-owner master data verified before generation
- Role descriptions understandable by business reviewers
- Review deadlines and coordinator escalation defined
- Removal provisioning reconciled to decisions
- SoD conflicts linked to mitigating controls with owners
- Target-system logging configured for firefighter sessions
- Every firefighter session log reviewed and signed off
- Evidence package (population, decisions, removals, sign-offs) retained per review cycle
How AskDona helps
Access review cycles produce exports, history reports, removal tickets, mitigating-control documentation and firefighter logs, and auditors want them tied together. AskDona reads that evidence package against your control description and audit requirements, checks that each decision has follow-through, flags gaps such as unreviewed sessions or missing mitigations, and cites the exact file and row. Run a sample access review evidence check on your last cycle before the auditors do. AskDona shows the evidence; your control owners decide.
Editor’s note: Workflow details come from SAP Learning course pages, which describe standard SAP Access Control functionality; your release and configuration may differ. The SAP IDM dates come from a SAPinsider article that promotes a vendor whitepaper. The SEC guidance is cited through a law-firm summary. This is not audit advice.
FAQ
What is a user access review in SAP? A periodic certification in which managers or role owners confirm that each user’s SAP role assignments are still needed, with unneeded roles removed.
What is an SoD review in SAP GRC? A periodic review of users whose access creates segregation-of-duties risks, deciding whether the access is still needed and how it is mitigated.
What is a firefighter log review? The review and sign-off by a firefighter controller of the activity logs from each emergency access session.
Can SAP user access reviews be automated? SAP Access Control automates generation, routing, reminders and removal provisioning. Reviewer judgment and evidence quality still need oversight.
How do you review access in SAP SuccessFactors? Review permission roles together with their granted and target populations, because users typically match several layered roles.
References
All pages opened and checked by October 19, 2026.
| Source | Type | Used for |
|---|---|---|
| SAP Learning: Performing User Access Review | Vendor training | UAR, SoD and firefighter ID review workflows |
| SAP Learning: Monitoring the Emergency Access Session | Vendor training | Firefighter log review |
| SAP Learning: SuccessFactors permission roles | Vendor training | Role-based permissions |
| SAPinsider, June 2026 | Analyst/community (vendor-sponsored) | SAP IDM maintenance dates |
| 17 CFR 229.308 (LII) | Regulation | ICFR reporting |
| Cooley, 2007 | Law firm | SEC guidance on IT general controls |