25 Years in SAP Security: 7 Lessons Every SAP Security Professional Should Know

When I started my career in SAP Security more than 25 years ago, the landscape looked very different. Many SAP customers were still relying heavily on authorization profiles, while role-based authorizations were gradually becoming the preferred approach with the introduction of the Profile Generator (PFCG). Much of our day-to-day work involved building authorization concepts, resolving authorization issues, tracing failed authorization checks, and helping businesses adopt a structured approach to access management.

I still remember spending hours with SU53, ST01 and the Profile Generator (PFCG), trying to understand why a user couldn't execute a transaction. At that time, solving authorization issues was considered the core of SAP Security.

Around the same time, organizations were beginning to realize that user access wasn't just an IT administration task - it was also a business risk. The introduction of Virsa Systems brought automated Segregation of Duties (SoD) analysis. For the first time, organizations could systematically identify access conflicts instead of relying on spreadsheets, manual reviews, or external audit observations. 

For many SAP security professionals, it marked the beginning of a more governance-driven approach to access management.

It was a privilege to meet the founder of Virsa Systems during one of the SAP conferences. Looking back, I didn't realize then how much Virsa would influence the future of SAP access governance.

Figure 1. Meeting Jasveer Gill, founder of Virsa Systems, during an SAP conference. Virsa transformed how SAP customers approached Segregation of Duties (SoD) and laid the foundation for modern SAP Access Governance. (Personal photo.)

Today, the SAP security profession looks very different from when I started my career. We've moved from SAP R/3 to S/4HANA, from on-premise systems to hybrid and cloud landscapes, from periodic access reviews to continuous monitoring, and now we're exploring how AI can help automate parts of security and governance.

Despite these changes, one thing has remained surprisingly consistent: the fundamentals of good SAP security haven't changed nearly as much as the technology around them.

Over the past 25 years, I've had the privilege of working with organizations of all sizes across multiple industries, helping them implement SAP security, strengthen governance, support audits, manage access risks, and navigate technology transformations. Although every implementation was unique, I noticed the same challenges appearing again and again, regardless of industry or geography.

This isn't intended to be a history lesson. It’s simply a collection of lessons that have consistently held true across hundreds of customer discussions, implementations, audits and SAP security reviews.

1. Security Has Always Been More About People Than Technology

During one security assessment, I asked a simple question: "Who owns user access?" Five different people gave me five different answers. That conversation taught me more about SAP Security than any authorization trace ever could.

When organizations experience security issues, the immediate reaction is often to look for a technical explanation. 

• Was a role designed incorrectly? 
• Was too much access assigned? 
• Was a security control missing?

Sometimes the answer is yes. More often, however, SAP rarely creates security problems by itself. Most problems originate from unclear ownership, inconsistent governance or poor business decisions.

I remember a customer who had spent months implementing SAP GRC. The project team considered it a success because the workflows were live, approvals were working and reports looked impressive. Six months later, they admitted something surprising. Nobody actually knew who owned user access. The tool was working perfectly. The process wasn't.

That's one of the biggest lessons my career has taught me: governance creates security, technology simply enables it.

Whether you're implementing a new authorization concept, reviewing access risks, or responding to audit findings, success depends far more on collaboration and accountability than on the software itself. The best security solutions are rarely the most complex - they're the ones that people understand, trust, and consistently follow.

2. Complexity Is Inevitable - Poor Design Isn't

One question I've been asked throughout my career is, "Why is SAP Security so complex?"

It's a fair question, especially for someone new to the field. When you look at an SAP landscape with thousands of roles, hundreds of custom transactions, multiple connected systems, and years of accumulated changes, it's easy to assume that complexity is the result of poor security design.

In reality, that's rarely the whole story.

In most SAP landscapes, complexity doesn't appear overnight. It accumulates over years of acquisitions, business expansions, custom developments, derived roles, composite roles, Fiori catalogs, regulatory changes and "temporary" access that somehow becomes permanent.

One pattern I've noticed is not to judge an authorization design simply by the number of roles it contains. I've seen organizations with relatively few roles struggle because those roles were poorly designed and overloaded with unnecessary access. I've also worked with global enterprises managing thousands of roles in a structured and disciplined way because they invested in clear naming standards, ownership, documentation, and governance.

Every mature SAP system becomes more complicated over time. That's normal. I've never walked into a 20-year-old SAP landscape and expected to see 200 beautifully designed roles. What concerns me isn't complexity itself. It's complexity that nobody can explain.

One of the mistakes I've seen repeatedly is treating role design as a one-time implementation activity. A role is created during a project, the project goes live, and then the role remains largely untouched for years. Meanwhile, the business changes, new transactions are introduced, responsibilities shift, and temporary access quietly becomes permanent.

Without regular review, even a well-designed authorization concept gradually loses its effectiveness.

Good SAP Security isn't about designing the perfect role on the first attempt. It's about building a model that can evolve with the business without becoming impossible to understand or maintain.

That requires more than technical knowledge. It requires an understanding of business processes, collaboration with functional teams, and the discipline to continuously simplify wherever possible.

Whenever I review a customer's authorization landscape, I don't ask whether it's complex. I ask whether the complexity is justified, documented, and manageable.

There's an important difference.

3. Segregation of Duties Is Important - But It Isn't the Whole Story

When Virsa first appeared, many organizations believed SAP Security had finally found the answer to Segregation of Duties.

The growing adoption of governance solutions made SoD analysis significantly easier, and today it's difficult to imagine an SAP security program without some form of SoD assessment. Preventing conflicting responsibilities remains one of the most effective ways to reduce the risk of fraud, financial misstatement, and operational errors.

However, experience has also taught me that it's possible to become too focused on SoD - or to misunderstand what a SoD solution is meant to achieve.

I've seen organizations successfully implement a SoD solution, celebrate the project's completion, and then, within a year, start viewing it as little more than another compliance burden. The expectation was that once the tool was in place, SoD risks would automatically disappear.

Unfortunately, that's not how SoD management works. One question I now ask every customer is simple:

"Who owns SoD remediation after go-live?"

Implementing a SoD solution isn't like installing antivirus software that automatically detects and removes threats. A SoD solution is primarily a detective control. It identifies conflicting access and highlights potential risks, but it doesn't resolve those risks on its own. The real work begins after the reports are generated - reviewing the findings, validating whether the risks are genuine, redesigning roles where appropriate, removing unnecessary access, or implementing suitable compensating controls. Those decisions require business involvement, governance, and informed judgment. They cannot simply be delegated to a tool.

I've also seen organizations proudly report that they had reduced their SoD violations by 80%, while at the same time leaving emergency access IDs largely unmanaged. Others spent months refining their SoD rule sets but paid little attention to sensitive transactions, privileged access, critical table maintenance authorizations, interface users, or custom-developed programs that introduced equally significant risks.

A successful SoD implementation isn't measured by how many violations a tool identifies or how many reports it produces. It's measured by how effectively an organization manages the risks those reports uncover as part of a broader access governance strategy.

A clean SoD report doesn't automatically mean an organization is secure.

Effective SAP Security requires a broader view of risk. It means understanding not only who has access, but how that access is being used, whether appropriate monitoring exists, and whether compensating controls are actually operating as intended.

Today, I view SoD as one important component of a much larger governance framework. It deserves attention, but it shouldn't consume all of it.

The strongest security programs are the ones that balance preventive controls like SoD with detective controls, continuous monitoring, periodic access reviews, privileged access management, and active business ownership.

Security isn't about producing the perfect SoD report for an auditor.

It's about ensuring that access across the SAP landscape remains appropriate, accountable, and aligned with the risks the organization is willing to accept.

4. Automation Doesn't Fix Broken Processes

One of the biggest changes I've witnessed over the past two decades has been the growing use of automation in SAP Security. What once involved emails, spreadsheets, and manual approvals is now handled through automated workflows, identity governance solutions, provisioning tools, and continuous monitoring platforms.

Automation has unquestionably improved efficiency. Access requests are processed faster, approvals are easier to track, and organizations have much better visibility into who has access to what.

But automation has also reinforced a lesson I've learned repeatedly throughout my career.

It doesn't fix broken processes.

I've seen organizations automate access requests without clearly defining who should approve them. I've seen approval workflows where managers routinely approved every request without understanding what access was being granted. In other cases, periodic access reviews became a simple checkbox exercise because reviewers lacked the context needed to make informed decisions.

The technology worked exactly as designed. The process didn't.

Before implementing any security solution, whether it's SAP GRC, cloud-based identity governance, or a custom workflow, it's worth asking a simple question:

Would this still be a good process if we had to perform it manually?

If the answer is no, automation is unlikely to solve the underlying problem.

The most successful implementations I've been part of didn't begin with technology. They began with conversations about ownership, governance, approval criteria, risk tolerance, and business accountability. Only after those questions were answered did automation become truly valuable.

Automation should make good processes more efficient - not make poor processes more difficult to recognize.

5. Cloud and AI Have Changed the Landscape - Not the Fundamentals

If someone had described today's SAP landscape when I started my career, it would have sounded like science fiction.

Organizations now operate hybrid environments that combine SAP S/4HANA, SAP Business Technology Platform (BTP), SAP Cloud Identity Services, SaaS applications, hyper scalers, APIs, mobile applications, and non-SAP systems. Identity extends well beyond the traditional SAP ERP system, and security professionals are expected to understand technologies that didn't even exist twenty-five years ago.

We're seeing AI assist with access analysis, anomaly detection, role recommendations, policy generation, and operational support. These capabilities will undoubtedly become more sophisticated over the coming years, helping security teams work more efficiently and identify risks that might otherwise go unnoticed.

Yet despite these advances, I don't believe the fundamentals have changed.

Users should still receive only the access they need to perform their jobs. Business owners should remain accountable for approving access. Privileged users require additional oversight. Risks should be identified, assessed, and periodically reviewed. Governance should always take precedence over convenience.

The platforms continue to evolve, but the fundamentals remain remarkably consistent: least privilege, business ownership, accountability and regular access reviews.

Every major technological shift - from SAP R/3 to ERP, from ERP to S/4HANA, from on-premise to cloud, and now from traditional automation to AI - has introduced new capabilities and new challenges. But none of these innovations has replaced the need for sound judgment and strong governance.

Twenty-five years ago, if someone had told me I'd spend time discussing AI-generated role recommendations or cloud identity services, I probably wouldn't have believed them. Yet here we are. I'm equally certain that ten years from now we'll be discussing technologies we can't even imagine today.

What distinguishes experienced SAP security professionals isn't simply their ability to use the latest tools. It's their ability to apply timeless security principles to whatever technology comes next.

That's a lesson I believe will remain true long after today's technologies have been replaced by tomorrow's.

6. Continuous Improvement Is Better Than Chasing Perfection

One mindset that has changed for me over the years is the pursuit of perfection.

Early in my career, I believed a security design had to be as close to perfect as possible before a project went live. Every role needed to be optimized, every authorization carefully reviewed, and every risk eliminated.

It didn't take many implementations before I realized that a perfect authorization model rarely survives the first business change.

Businesses don't stand still. New processes are introduced, acquisitions happen, regulations evolve, employees change roles, and systems are enhanced. An authorization model that is well designed today may no longer reflect the business a year from now.

That's why I've come to see SAP Security as a continuous journey rather than a destination.

The organizations that consistently maintain a strong security posture aren't necessarily the ones with the most sophisticated role designs or the fewest SoD violations. They're the ones that regularly review user access, remove unnecessary authorizations, simplify roles where possible, act on audit findings, and continuously refine their governance processes.

I've also learned that simplicity has long-term value. A role that's easy to understand and maintain often delivers better results than one that's technically perfect but too complex for anyone to manage confidently.

Progress, in my experience, almost always beats perfection.

7. Never Stop Learning

When I entered SAP Security, success largely depended on understanding authorization objects, profiles, transactions, and role design. Those skills are still important today, but the profession has expanded far beyond them.

Today's SAP security professionals are expected to understand cloud architectures, identity governance, cybersecurity, compliance frameworks, APIs, AI, automation, and increasingly complex business processes. It's no longer enough to know how SAP authorizations work. We also need to understand how those authorizations support business objectives while managing risk across an interconnected technology landscape.

That may sound challenging, but I see it as one of the most exciting aspects of our profession.

Over the past 25 years, I've had the opportunity to learn from customers, auditors, developers, functional consultants, Basis administrators, project managers, and fellow security professionals. Every implementation, every audit, and every production issue taught me something new. Some of the most valuable lessons came from projects that didn't go exactly as planned.

Writing SAP PRESS books taught me something unexpected. Explaining SAP Security & GRC concepts to thousands of readers often challenged assumptions I'd held for years.

One thing has become very clear to me: the most successful professionals are rarely the ones who believe they know everything. They're the ones who remain curious.

They ask questions. They explore new technologies. They listen to different perspectives. Most importantly, they never stop learning.

In a profession that's constantly evolving, curiosity is one of the most valuable skills you can develop.

Final Thoughts

When I look back on the past 25 years, I don't just remember the technologies. I remember the people.

The customers who trusted us with their most critical systems. The colleagues who challenged my thinking. The auditors who asked difficult questions. The project teams that worked through late nights before go-live. The mentors who shared their knowledge, and the young consultants who reminded me that every generation brings fresh ideas and a different perspective.

Technology will continue to evolve, just as it always has. AI will become more capable. Cloud adoption will grow. New regulations will emerge, and the definition of SAP Security will continue to expand.

But I believe the qualities that define a good SAP security professional will remain remarkably consistent.

Understand the business before implementing controls. Build governance before relying on technology. Focus on managing risk rather than simply satisfying compliance requirements. Keep things as simple as they can be, but no simpler. And most importantly, never stop learning.

Those lessons have guided me throughout my career. 

If I were starting my career again today, I'd still choose SAP Security & GRC without hesitation. Few professions allow you to continuously learn while helping organizations protect their most critical business processes. That's what has kept me passionate about this field for more than twenty-five years, and if the next twenty-five years are anything like the last, I know I'll still be learning.

One of the things I'm most proud of isn't a project or an implementation. It's the SAP Security community we've built over the years. When I launched the first version of SAP Security Expert in 2010, I simply wanted a place to share practical knowledge.  

Figure 2. The original SAP Security Expert website, launched in 2010. Fifteen years later, the mission remains unchanged: sharing practical SAP Security and SAP GRC knowledge with the community.

SAP Security Expert has always been more than a website to me. It has been a place to learn, share ideas, solve problems, and connect with professionals who are passionate about SAP Security.

As the technology continues to evolve, my commitment remains unchanged- to keep sharing practical knowledge, real-world experiences, and lessons learned from the field. I hope you'll continue to be part of that journey.