BLOG

How not to overdo the permissions? – Least Required Access in SAP

In the world of ERP systems such as SAP, the issue of user privileges is crucial – not only for security, but also for the efficiency of the entire organization. And yet, in practice, one often encounters situations in which users have access to a much broader set of functions than they realistically need. Sometimes “just in case,” sometimes “because it was faster,” and sometimes no one simply took the trouble to check it.

Meanwhile, there is a principle that should be the foundation of any access management policy:Least Privilege Principle (LPP). In short, a user should have exactly as much privilege as he or she needs to perform his or her duties. Neither less nor more.

A survey of 225 organizations revealed that 85% of permissions had not been used in the last 90 days, and one in three users had access to systems they did not use at all. This data leaves no illusions – redundant access is a real and widespread problem. Most users have far too broad privileges, which not only increases the attack surface, but also poses an audit risk.

 

Why does it really matter?

The LPP rule is not just common sense – it is one of the pillars of information security and regulatory compliance. Overly broad powers can result:

  • fraud or data manipulation,
  • accidental errors that disrupt processes or cause data loss,
  • violation of the principle of separation of duties (SoD),
  • non-compliance with regulations, such as RODO or SOX,
  • more difficult audits and a larger field for cyber attacks.

 

Stories from life, or what it looks like in practice.

Let’s take a look at some examples of not applying the principle of Least Required Access:

Example 1: Accounting clerk with full access to invoicing cycle

A person in the finance department had access to all transactions in the invoicing cycle: from entering incoming invoices (MIRO), to posting documents (FB60), to approving payments (F110).

Risk: The employee could independently carry out the entire process – from creating the document to executing the transfer. Such access violates the principle of separation of duties and makes it significantly more difficult to later determine who was responsible for what.

Solution: limit access to one role – e.g., only MIRO or only FB60 – and assign payment approval to another user. It is worth implementing a workflow and clearly defining the owners of each step in the process.

Example 2: Employee in purchasing department with access to sales terms and conditions

The purchasing clerk not only had access to purchase orders (ME21N, ME22N), but also to sales price terms (VK11). The problem was that he didn’t need this data, and editing it could have strategic consequences.

Risks: Unauthorized change in pricing policy – accidental or intentional.

Solution: Clearly separate purchasing and sales roles and restrict access to data only within the respective units.

Example 3: An employee after a change of position

After moving from the warehouse to the controlling department, the employee retained the old rights and received new ones. The result? Simultaneous access to warehouse documents and cost data.

Risks: Redundant access to processes outside current responsibilities, potential SoD conflicts.

Solution: Any change of position should involve a full review of permissions – not only adding new roles, but also taking away unnecessary ones.

These examples show how easy it is in practice to give too much authority – often as a result of haste, lack of review or ill-considered combining of roles. Each of the cases described makes it clear that even seemingly minor omissions can lead to serious risks that can be easily eliminated by applying the LPP principle.

How to act according to the LPP principle?

Applying the principle of Least Required Access requires not only awareness of the risks, but also specific organizational and technical measures – preferably implemented systematically and with long-term security in mind. Here are some suggestions:

  • Create business roles that match actual responsibilities – no unnecessary transactions.
  • Establish organizational fields and limit the scope of data (e.g., to a specific company or warehouse).
  • Use thoughtful approval and entitlement review processes – especially when changing roles or positions.
  • Verify SoD conflicts before granting access.
  • Recertify entitlements regularly, such as every 6 or 12 months.
  • Support yourself with SAP tools such as GRC Access Control, SUIM, ST03N or transaction logs.

And if you want to really organize the subject of accesses, it’s worth reaching for dedicated solutions such as smartGRC (https://smartgrc.eu/). With them, you can, among other things:

  • conduct periodic periodic reviews of authorizations,
  • Implement a workflow for granting and approving access,
  • manage the SoD risk base, which definitely facilitates control and improves system security.

 

LPP vs. user convenience

A common myth is the belief that limiting authority makes people less comfortable. In fact, the exact opposite is true.

Well-designed roles – consistent with responsibilities and cleansed of redundant transactions – make users:

  • They find the needed functions faster,
  • are not overwhelmed by unnecessary options in the interface,
  • They are less likely to make mistakes resulting from accidentally clicking “the wrong thing.”

The Principle of Least Required Access therefore improves not only security, but also usability of the SAP system. It’s a cleaner, clearer interface – and therefore a better experience for the end user.

 

LPP and safety regulations and standards

It is also worth remembering that the principle of Least Required Access is not just good practice – it is one of the formal requirements of many international standards and regulations on information security and data protection.

Here are some examples:

  • ISO/IEC 27001 – requires controlling access to resources on a business need basis.
  • NIST SP 800-53 – identifies the principle of least privilege as the primary mechanism for protecting information systems.
  • RODO/GDPR – imposes an obligation to limit access to personal data to only those who actually need it (minimization principle).
  • SOX (Sarbanes-Oxley Act) – requires access controls in the context of financial statement integrity.

Adherence to the LPP principle therefore helps not only minimize operational risks, but also maintain compliance with applicable regulations and standards, which can be crucial during audits and external inspections.

 

What do you gain by using LPP?

Implementing the principle of Least Required Access is not just about compliance and security. It’s also a number of tangible benefits:

  • Fewer problems with audits – thanks to better control over accesses.
  • Faster and clearer controls – structured roles mean fewer exceptions to translate.
  • Lower access management costs – fewer roles to maintain, fewer requests to IT.
  • Greater transparency of accountability – it is clear who is responsible for what.
  • Fewer user errors – because they only have access to what they really need.
  • “Cleaner” SAP system – without overgrown roles and historical permissions.

 

Finally, common sense as a standard

The Principle of Least Required Access is not an exaggerated caution, but a professional approach to security at SAP. It protects not only data and processes, but also the organization’s reputation.

That’s why it’s worth taking a moment to consider: is this access really necessary? If not – this is the perfect time to limit it.

Sources:

  1. Cloud Security Alliance. (2024). Mastering Least Privilege: Cutting Unused Access Without Cutting Corners. Retrieved from https://cloudsecurityalliance.org/blog/2024/05/30/mastering-least-privilege-cutting-unused-access
  2. (n.d.). What is Least Privilege? Retrieved from https://www.cyberark.com/what-is/least-privilege/
  3. Edwards, M. (2025). Annex A.5.3: Segregation of Duties. Online. Retrieved from https://www.isms.online/iso-27001/annex-a/5-3-segregation-of-duties-2022/
  4. National Institute of Standards and Technology (NIST). (n.d.). Least privilege. Downloaded from https://csrc.nist.gov/glossary/term/least_privilege
  5. (2024). Secure SAP with Effective Access Governance. Retrieved from https://www.safepaas.com/articles/secure-sap-with-effective-access-governance/
  6. (2025). Access certification: An ultimate guide. Zluri. Retrieved from https://www.zluri.com/blog/access-certification
  7. (2024). Official smartGRC product page. Downloaded from https://smartgrc.eu/

Chcesz wiedzieć więcej? Skontaktuj się z nami.

Wypełnij poniższy formularz. Zwykle odpowiadamy w ciągu dwóch godzin.