Common SAP Security Audit Findings and How to Fix Them

If you've participated in a few SAP security audits, you've probably noticed a pattern. The findings may come from different auditors, but many of the observations are surprisingly similar.

Whether the audit is performed by an internal audit team, external auditors, SOX compliance specialists, or regulatory agencies, the same observations continue to appear year after year. Excessive privileges, Segregation of Duties conflicts, dormant user accounts, over-privileged roles, and missing access reviews are among the most common issues identified across SAP landscapes.

In my experience working with SAP customers across manufacturing, banking, retail, healthcare, oil & gas, and the public sector for more than two decades, one thing has become clear to me: most organizations don't struggle because they lack security tools. They struggle because the controls they implemented years ago gradually become less effective as the business evolves.

Most organizations already have security policies, documented procedures, and often SAP GRC or other governance solutions in place. The challenge isn't the absence of controls - it's ensuring those controls continue to operate effectively as the business evolves.

Understanding why auditors repeatedly identify these issues is the first step toward building a mature SAP security program.

Why Do SAP Security Audit Findings Keep Reappearing?

One misconception I hear quite often is that an audit finding automatically means the SAP environment is insecure. That’s rarely the case.

In my experience, most audit findings simply indicate that a security control is missing, isn't operating consistently, or no longer reflects how the business works.

Often, recurring audit findings point to governance gaps rather than technical shortcomings.

For example, assigning SAP_ALL to a consultant during an implementation or go-live project is often completely justified. The issue begins when that temporary access quietly becomes permanent because nobody revisits it after the project ends. 

Similarly, a SoD conflict isn’t always evidence of fraud. It often reflects business growth, organizational restructuring, or emergency operational decisions that were never revisited.

Auditors focus on these areas because they directly influence the confidentiality, integrity, and availability of business data while increasing the organization’s exposure to fraud, financial misstatement, and cyber threats.

Let’s look at the findings that appear most frequently and more importantly, how to address them effectively.

1. Excessive Privileged Access

One of the very first requests in almost every SAP security audit is a list of users who have been granted SAP_ALL, SAP_NEW, or other highly privileged roles. Auditors start here because these users can potentially bypass many of the preventive controls built into SAP.

From an auditor’s perspective, unrestricted access represents a significant risk because it allows users to bypass many preventive controls built into SAP.

I can't count the number of SAP systems where I've found consultants still holding SAP_ALL months after the go-live. Nobody intended to leave that access in place. It simply became one of those things everyone assumed someone else had already cleaned up.

Instead of immediately removing privileged access, organizations should first understand how it is being used. Reviewing transaction usage, redesigning roles based on actual business responsibilities, and replacing permanent administrative access with controlled emergency access processes significantly reduces both operational disruption and audit risk.

The objective isn't to eliminate privileged access altogether. It's to ensure that every privileged assignment is justified, approved, periodically reviewed, and removed when it's no longer required.

2. Segregation of Duties Conflicts

Ask any SAP auditor what they look for first, and Segregation of Duties will almost always be near the top of the list. There's a good reason for that.

Consider a user who can create a vendor, modify bank account details, and process vendor payments. Individually, each authorization may be legitimate. Combined, they create an opportunity for fraudulent payments without independent oversight.

In practice, many SoD conflicts arise unintentionally. Organizations merge departments, employees take on temporary responsibilities, or copied roles introduce unexpected combinations of access.

Generating a SoD report once a year may satisfy a compliance requirement, but it rarely provides effective risk management.

Organizations with mature SAP security programs review SoD risks continuously, validate whether the conflicts are genuinely required, and implement mitigation controls only when removing the access isn't practical.

3. Poor Role Design

Many audit findings originate long before the audit begins - during role design.

I've worked with organizations managing thousands of custom roles that had evolved over more than a decade. Many of those roles had been copied repeatedly, modified by different teams, and never properly reviewed.

Over time, this creates excessive access, duplicate roles, inconsistent authorization values, and an authorization landscape that becomes increasingly difficult to understand or maintain.

Good role design isn't about creating the highest number of roles or having a master/derived design. It's about creating roles that accurately reflect business responsibilities while remaining simple enough to maintain over time.

Periodic role optimization, reviewing SU24 proposals, removing obsolete transactions, and standardizing naming conventions can significantly improve both security and administration.

A well-designed authorization concept also makes future audits much easier because access decisions become easier to explain and justify.

4. Dormant and Orphaned User Accounts

This is one of the easiest audit findings to prevent, yet it continues to appear in organizations of every size.

• Employees resign.
• Contractors complete projects.
• Temporary consultants leave.

In one customer environment, we discovered over 300 users who hadn't logged in for more than a year. None of them had been compromised - but if even one credential had leaked, an attacker would have had access that nobody was actively monitoring.

Organizations should establish automated processes to identify users who have not logged into SAP within a defined period and review whether continued access is justified. Integrating SAP identity management with HR processes further reduces the likelihood of orphaned accounts remaining active after employee termination.

As a general principle, user access should never outlive the business requirement that justified it in the first place.

5. Critical Authorization Objects Without Justification

Not every security risk comes from SAP_ALL.

Authorization objects in groups - S_TABU*, S_USER*, S_PROGRAM, S_RFC*, and S_DEVELOP provide powerful capabilities that can significantly affect system security.

During audits, it's common to find these authorization objects assigned to users simply because they inherited an existing role or someone copied another role without reviewing its contents.

Instead of focusing only on role names, organizations should periodically review critical authorization objects directly and validate whether each assignment continues to support legitimate business activities.

Least privilege should apply not only to roles but also to individual authorization values.

6. Missing Periodic User Access Reviews

Business responsibilities change constantly. Access that was appropriate a year ago may no longer reflect the user's current responsibilities.

This is why User Access Reviews have become a standard governance practice across many industries.

Unfortunately, many organizations still rely on spreadsheets and email approvals, making reviews time-consuming, inconsistent, and difficult to audit.

An effective access review should give business owners enough information to make an informed decision rather than asking them to approve access blindly.

For example, reviewers benefit from seeing transaction usage, last login date, licensing information, business ownership, SoD conflicts, and critical authorizations before making a decision.

When reviews become evidence-based rather than checkbox exercises, both security and compliance improve significantly.

7. Weak Logging and Security Monitoring

Enabling SAP Security Audit Logs (SAL) is only the beginning. During almost every audit, one question eventually comes up:

“Who reviews the logs?”

If security events are collected but never monitored, the organization may not detect suspicious activities until long after an incident has occurred.

Organizations should define which events require monitoring, establish ownership for reviewing alerts, integrate SAP logs with enterprise SIEM platforms where appropriate, and periodically verify that logging remains enabled after upgrades or system changes.

Logging is valuable only when someone is actively reviewing and responding to what the logs reveal.

Moving Beyond Audit Compliance

One observation I've made over the years is that organizations with the fewest audit findings usually aren't the ones spending weeks preparing before an audit. They're the ones that treat SAP security as an ongoing business process rather than an annual compliance exercise. Because governance happens continuously, they're already prepared when the auditors arrive.

• They regularly review privileged access.
• They optimize roles instead of continuously adding new ones.
• They automate access reviews.
• They monitor critical activities rather than waiting for annual assessments.

More importantly, security activities become part of normal operations instead of something that's only revisited before an audit.

When governance becomes part of day-to-day operations, audit findings naturally decrease because the underlying risks are addressed continuously rather than retrospectively.

Final Thoughts

None of the audit findings discussed in this article are new. Most SAP security professionals have encountered them repeatedly over the years. The difference is that mature organizations address these risks continuously instead of waiting until they're highlighted in an audit report.

They are well understood, predictable, and, in most cases, entirely preventable.

While every organization has unique business processes, the underlying principles remain consistent: provide only the access users genuinely need, review that access regularly, monitor privileged activities, and continuously improve authorization design as the business evolves.

In my experience, passing an audit should be viewed as a milestone - not the ultimate objective. Strong SAP security is built through consistent governance every day, not just during audit season.

The real objective is to build an SAP environment where security controls operate consistently every day, regardless of whether an audit is scheduled.

Organizations that adopt this mindset don't just perform better during audits - they build a stronger, more resilient SAP security program that reduces operational risk, strengthens regulatory compliance, and increases confidence in the integrity of their SAP landscape.