Picture the scene. One side of the table: a seasoned SAP Security team. Certified professionals. Years of experience. Behind them — a GRC platform running six figures a year, an IAM solution that took eighteen months to implement, a SIEM, dashboards, workflows, reports. The infrastructure of seriousness.
Other side: an auditor. A laptop. Ten Excel formulas.
The audit begins. Within four hours, the findings start rolling in.
Six findings. Any one of them is a serious control failure. All six together? That's an audit that ends careers.
The tools didn't fail. The team didn't fail. Something else did — and until you understand what that something is, the next audit will look exactly the same.
Nobody Owned the Audit
In most organisations, SAP security is not treated as a living compliance discipline. It's treated as a technical function that gets reviewed once a year when an auditor shows up.
The GRC team owns the access framework. The BASIS team owns the system configuration. The IAM team owns provisioning. The compliance team owns the audit checklist. And none of them talk to each other in the language of the auditor.
"The auditor does not care about your architecture. They care about outcomes. Is this user active? Does this account have this access? Was this review completed? Yes or no."
The security team speaks in system terms. The auditor speaks in control terms. This translation gap — between what the tools show and what the audit requires — is where organisations get destroyed.
And the tragedy is that every single one of those six findings is preventable. Not with better tools. Not with more headcount. With discipline, collaboration, and internal audit cadence.
Breaking Down the Six Failures
1. Terminated Users Active in Production
This is the most embarrassing finding because it's the most obvious. When an employee leaves, their SAP account should be locked immediately. But in most organisations, HR, IT provisioning, and the SAP team operate in silos. HR closes the ticket. IT disables the Windows account. Nobody tells SAP.
The fix is not a new tool. It's a joiner-mover-leaver process with SAP integrated as a mandatory step, and a weekly reconciliation report confirming it worked.
2. UAR Not Completed
User Access Reviews are the single most commonly failed audit control in SAP environments. Not because the work is impossible — but because it's treated as a one-time event rather than a continuous process. The review cycle gets triggered by the audit calendar, not by business reality.
When UAR is done continuously — roles reviewed as they're assigned, access certified at regular intervals — no single audit cycle becomes a crisis.
3. Incorrect System Parameters
Parameters like login/min_password_lng, rdisp/gui_auto_logout — these are the SAP equivalent of a door lock. Set during go-live and then forgotten. Basis changes something for performance. A patch resets a value. Nobody checks.
A quarterly parameter baseline comparison against your security policy takes thirty minutes with the right query. Most teams don't run it.
4. SAP_ALL Assigned
SAP_ALL is a composite profile that grants every authorisation in the system. There is no legitimate reason for a production user to carry it. Emergency access is managed through firefighter tools with logging. Yet it gets assigned during go-live, during migrations, during troubleshooting — and then it stays.
A weekly automated check for SAP_ALL, SAP_NEW, and other critical composite profiles should be a standing report, not an audit discovery.
5. DDIC Open
DDIC — the data dictionary user — should be locked in production. Full stop. It carries massive implicit authorisations. If an auditor finds it open, they have found a critical vulnerability that needs immediate remediation, not an explanation.
6. Client Open
Client settings control whether modifications, programs, and transports can be made to a production client. A production client left open is a change management failure and a security failure simultaneously. Two days of exposure is two days of risk that cannot be retroactively closed.
Client status should be validated as part of every change window close-out. Automatically.
The Path Forward: Plan, Execute, Automate, Collaborate
Step 1: Run Your Own Audit First
Before any external auditor walks in, run the audit yourself. Use the same checklist they will use — the SAP Security Baseline, your internal control framework, your industry regulator's guidance. Find your own findings. Fix them.
The goal is not to hide problems from auditors. It's to not be surprised by them.
Step 2: Build a Standing Compliance Calendar
Compliance is not an event. It's a calendar. Map your control checks to time-boxes:
| Frequency | Control Checks |
|---|---|
| Daily | Locked/terminated user reconciliation, critical parameter spot-check |
| Weekly | SAP_ALL / SAP_NEW / critical profile assignment report, DDIC & client status |
| Monthly | Full access review for privileged accounts, SoD conflict sweep |
| Quarterly | Full parameter baseline comparison, UAR cycle completion, role usage analysis |
| Pre-Audit | Full internal audit run, evidence collection, remediation log |
Step 3: Automate What You Currently Review Manually
Every control check that a human runs manually is a control check that will eventually be missed. Not because of negligence — because humans have competing priorities, and the audit cycle is relentless.
Automate terminated user detection, parameter drift alerts, UAR reminders and escalations, critical profile assignment notifications, and client and DDIC status checks. Not once a year. Continuously.
Step 4: Make Security and Audit Speak the Same Language
The GRC team, the BASIS team, the IAM team, and the compliance team need a shared control vocabulary. When a finding is raised, every team should immediately understand what it means in their domain and what their contribution to remediation is.
Create a control matrix that maps every audit check to a system owner, a process owner, and an evidence artifact. Then practise it — internally, every quarter.
Step 5: Prepare Evidence — Don't Explain Situations
There is a temptation, when an audit goes badly, to treat the auditor as an adversary. This is exactly wrong.
Auditors are looking for evidence that controls exist and work. Give them that evidence — organised, current, and accurate. A clean evidence pack, organised by control area, with timestamps and named owners, tells the story of a mature compliance function. It shifts the conversation from "why didn't you know?" to "here's how we manage it."
"The organisations that consistently pass audits are not the ones with the most expensive tools. They are the ones who treat audit readiness as a continuous practice, not a periodic panic."
What Technology Should Actually Do
This is not an argument against GRC platforms, IAM solutions, or security monitoring tools. These are valuable investments. But they are investments in capability — not in outcomes.
A GRC platform that nobody queries is a very expensive filing cabinet. An IAM solution that doesn't integrate with your HR termination process protects nothing. A SIEM that generates alerts nobody reviews is noise, not security.
The technology layer succeeds when it is:
- Connected — to the real-time state of your SAP systems, not to monthly exports
- Actionable — surfacing findings that map directly to audit controls
- Collaborative — giving both technical and compliance teams a shared view
- Continuous — running checks on a schedule, not on demand
- Explainable — producing evidence that an auditor can read without a decoder ring
The gap between tool and outcome is always filled by people, process, and discipline. No platform eliminates that gap. The best ones make it much smaller.
The Leader's Responsibility
If you are a CISO, a Head of SAP Security, a GRC Director, or a Compliance Leader — this one is for you.
The audit findings above are not technical failures. They are leadership failures. Not because you didn't care. Because the system around you — the processes, the handoffs, the meeting cadences, the shared ownership — was not built for continuous compliance.
You cannot fix that by buying another tool. You fix it by owning the outcome personally. By making audit readiness a standing agenda item in every security leadership meeting. By holding process owners accountable for their control areas. By running internal audits that are taken as seriously as external ones.
And then — when the auditor does walk in — you hand them an evidence pack, explain your control environment, and have a conversation about continuous improvement rather than emergency remediation.
That is what security leadership looks like.
Frequently asked questions
What are the most common SAP audit findings?
The recurring set: terminated users still active in production, incomplete User Access Reviews, incorrect system parameters, SAP_ALL assigned in production, the DDIC default account left open, and clients left open. Any one is a serious control failure; together they signal a systemic gap.
Why do expensive GRC tools and big teams still fail audits?
Because the tooling and headcount don't automatically translate into continuous verification. An auditor with a laptop and a few Excel formulas can surface terminated users, missed UARs and open defaults in hours — findings that six-figure platforms didn't catch because nobody was checking continuously.
How quickly can an auditor find these issues?
Fast. In a typical review the findings start appearing within about four hours — terminated users, missing reviews, misconfigured parameters — because they're mechanical checks against live data that most teams simply aren't running between audits.
How do you stop the same findings recurring every year?
By moving the mechanical checks from annual to continuous: detect terminated and dormant users, parameter drift, and excessive access as they occur, and keep audit-ready evidence on hand. Continuous verification is what closes the gap that periodic reviews leave open.