¿Cómo no excederse con las autorizaciones? - Principio de Mínimo Privilegio en SAP

In the world of ERP systems like SAP, user authorizations are a critical factor for both security and smooth business operations. Yet surprisingly often, users end up with far more access than they actually need. Sometimes "just in case," sometimes "because it was quicker." And sometimes simply because no one bothered to verify it. There is, however, a principle that should form the foundation of any authorization management policy: the Least Privilege Principle (LPP). In short - users should only be granted the access strictly necessary to perform their business tasks. Nothing less, but also nothing more. The scale of the problem is illustrated by a study conducted across 225 organizations: as much as 85% of assigned authorizations were not used during the last 90 days, and 1 in 3 users had access to systems they hadn't logged into at all. These numbers highlight how often excessive access is granted by default or forgotten during role changes. And every such access means a potential risk: of data leakage, fraud, error, or compliance violations.  

¿Por qué es tan importante?

The LPP is not just a best practice. It is one of the pillars of information security and regulatory compliance. Granting overly broad authorizations can lead to:

• fraude financiero y manipulación de datos,
• errores accidentales que provocan pérdida de datos o interrupciones del proceso,
• violación de la segregación de funciones (SoD),
• incumplimiento de regulaciones (p. ej. GDPR, SOX),
• auditorías más difíciles y una mayor superficie de ataque para los ciberdelincuentes.

 

Casos reales: cómo se ve en la práctica

Let's take a look at several examples where the Least Privilege Principle was not applied: Ejemplo 1: Empleado de contabilidad con acceso total al ciclo de facturación An employee in the finance department had access to all transactions within the invoicing cycle: from entering incoming invoices (MIRO), through document posting (FB60), to payment approvals (F110). Risk: The employee could independently complete the entire process - from document creation to executing the payment. This level of access violates the segregation of duties principle and makes it significantly harder to determine who was responsible for which part of the process. Solución: Limit access to one role only - e.g. either MIRO or FB60 - and assign payment approval to a different user. It's also worth implementing a workflow and clearly defining ownership of each stage of the process. Ejemplo 2: Empleado de compras con acceso a condiciones de venta An employee in the purchasing department had access not only to purchase orders (ME21N, ME22N), but also to sales pricing conditions (VK11). The problem? This data wasn't needed for their role, and editing it could have strategic consequences. Risk: Unauthorized modification of pricing policy - either accidental or intentional. Solución: Clearly separate purchasing and sales roles and limit access to data strictly within relevant organizational units. Ejemplo 3: Empleado tras un cambio de rol After transferring from the warehouse to the controlling department, the employee retained their old authorizations and received new ones. The result? Simultaneous access to warehouse documents and cost-related data. Risk: Excessive access to processes outside current responsibilities; potential SoD (Segregation of Duties) conflicts. Solución: Each role change should trigger a full access review - not just adding new roles but also removing those no longer needed. These examples show how easily excessive access can be granted - often due to haste, lack of periodic reviews, or careless role combinations. Each of these cases highlights how even seemingly minor oversights can lead to serious risks that are easy to eliminate by applying the LPP.  

¿Cómo aplicar el LPP en la práctica?

Applying the Least Privilege Principle requires not only awareness of potential risks but also concrete organizational and technical actions - ideally implemented systematically and with long-term security in mind. Here are some suggestions:

• Design business roles based on the actual scope of responsibilities - without unnecessary transactions.
• Define organizational fields and limit data access (e.g., to a specific company code or warehouse).
• Usa procesos estructurados de aprobación y revisión - especially during role or position changes.
• Verifica los conflictos de SoD (Segregación de Funciones) before granting access.
• Recertifica el acceso de los usuarios regularmente, e.g., every 6 or 12 months.
• Leverage SAP tools such as GRC Access Control, SUIM, ST03N, or transaction logs.

If you want to truly streamline access management, it's worth investing in dedicated solutions like smartGRC (https://smartgrc.eu/). These tools allow you to:

• conduct periodic access reviews,
• Implement workflows for access request and approval processes,
• gestionar una base de datos de riesgos SoD, which significantly improves control and enhances the security of your SAP environment.

 

LPP y la comodidad del usuario

A common myth is that limiting user access makes work less convenient. In reality, it's quite the opposite. Well-designed roles - aligned with actual responsibilities and stripped of unnecessary transactions - help users:

• encuentran más rápidamente las funciones que necesitan,
• evitan verse abrumados por opciones innecesarias de la interfaz,
• cometen menos errores causados por hacer clic en "lo equivocado".

The Least Privilege Principle improves not only SAP system security but also its usability. It creates a cleaner, more intuitive interface - resulting in a better experience for the end user.  

LPP y estándares & regulaciones de seguridad

It's also important to remember that the Least Privilege Principle is not just a good practice - it is a formal requirement in many international standards and data protection regulations. Here are a few examples:

• ISO/IEC 27001 - requires access to be granted based on business need.
• NIST SP 800-53 - identifies the least privilege principle as a foundational control for protecting IT systems.
• RODO/GDPR - enforces data minimization, meaning access to personal data must be restricted to those who truly need it.
• SOX (Sarbanes-Oxley Act) - mandates access control to ensure the integrity of financial reporting.

Following the LPP not only minimizes operational risks but also helps maintain compliance with applicable laws and standards - which is often critical during audits and external inspections.  

¿Qué se gana aplicando el LPP?

Implementing the Least Privilege Principle is not just about compliance and security. It also brings a number of practical benefits:

• Fewer audit issues - thanks to better control over access rights.
• Revisiones más rápidas y transparentes - well-structured roles mean fewer exceptions to explain.
• Lower access management costs - fewer roles to maintain, fewer IT support requests.
• Greater transparency of responsibilities - it's clear who is responsible for what.
• Fewer user errors - because users only have access to what they truly need.
• A "cleaner" SAP system - no oversized roles or outdated permissions lingering in the background.

 

En conclusión - el sentido común como estándar

The Least Privilege Principle is not about excessive caution - it's a professional approach to SAP security. It protects not only data and processes but also the organization's reputation. That's why it's worth taking a moment to ask: ¿Es realmente necesario este acceso? If the answer is no - that's the perfect moment to reduce it. References

1. Cloud Security Alliance. (2024). Dominar el mínimo privilegio: eliminar accesos no usados sin atajos. Retrieved from https://cloudsecurityalliance.org/blog/2024/05/30/mastering-least-privilege-cutting-unused-access
2. (n.d.). ¿Qué es el mínimo privilegio? Retrieved from https://www.cyberark.com/what-is/least-privilege/
3. Edwards, M. (2025). Anexo A.5.3: Segregación de funciones. ISMS.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. Retrieved from https://csrc.nist.gov/glossary/term/least_privilege
5. (2024). Asegurar SAP con una governance de accesos eficaz. Retrieved from https://www.safepaas.com/articles/secure-sap-with-effective-access-governance/
6. (2025). Certificación de accesos: guía definitiva. Zluri. Retrieved from https://www.zluri.com/blog/access-certification
7. (2024). Official smartGRC product site. Retrieved from https://smartgrc.eu/