# ERP Security and Permissions Design: RBAC Done Right

> How to design a robust role-based access control system for your ERP — covering principle of least privilege, separation of duties, and the common security mistakes that create compliance risk.

URL: https://www.matthewswong.com/en/blog/erp-security-permissions-design/

- Author: Matthews Wong (https://www.matthewswong.com/en/about/)
- Published: 2025-06-10
- Updated: 2025-06-10
- Category: ERP

An ERP system contains your company's most sensitive data: payroll figures, vendor contracts, bank account details, customer credit terms, and complete financial records. Get the permissions design wrong and you have a compliance risk, a fraud risk, and a data breach risk all in one. Compliance frameworks like SOC 2, ISO 27001, and — increasingly important for Indonesian businesses — the requirements of UU No. 27 Tahun 2022 (Undang-Undang Perlindungan Data Pribadi) all require controlled access and role-based permissions. This post covers how to design ERP security that satisfies auditors and protects your business.

## The Foundation: Principle of Least Privilege

Least privilege is the foundational principle: every user should have access only to the data and functions needed to do their job, and no more. In practice, this means a warehouse staff member can view inventory records but cannot see payroll data. A finance approver can approve payment vouchers but cannot delete records. An HR manager can see all employee data but cannot access financial records. The challenge in ERP design is that least privilege sounds simple but is complex to implement — it requires a complete map of every role, every resource, and every action before the system is built.

### Designing the Role Hierarchy

Start with the job functions, not the system permissions. For each job function in the business, ask: what data does this role need to read? What data does it need to create? What data does it need to modify? What data does it need to delete? Never? Design the role hierarchy from these answers. In a typical Indonesian SME ERP: System Admin (all access), Finance Manager (all finance modules, view-only HR), Finance Staff (create and read AP/AR, no delete, no approval), Finance Approver (read AP/AR, approve payments, no create), HR Manager (all HR, view-only finance), Employee (own profile, own leave requests, own payslips — nothing else). Each role is narrower than the one above it.

### Separation of Duties: The Fraud Prevention Layer

Separation of duties (SoD) ensures that no single user can complete a financially significant transaction alone. The classic example: the person who enters a vendor invoice should not be the same person who approves the payment. In ERP design, SoD rules are implemented as workflow constraints — the system enforces that an invoice cannot be approved by its creator. For Indonesian businesses, SoD is increasingly required by internal audit standards and is a key control that external auditors will test. Build SoD into the system design, not as a policy memo that depends on users following rules voluntarily.

> From my experience as a freelance ERP consultant: create a permission matrix before you build the system. The matrix has roles as columns and system actions as rows. Each cell is Allow, Deny, or Conditional (with the condition specified). Review the permission matrix with the internal audit function before development starts. Catching a separation-of-duties gap in a spreadsheet costs nothing. Catching it in a production system means reworking workflows and re-training users.

## Field-Level and Record-Level Security

Module-level access (can this user access the AP module?) is the first layer of security. But some data requires finer control. Field-level security restricts which fields within a record a user can see or edit — a Finance Staff member can see vendor name and invoice amount but not the vendor's bank account details. Record-level security restricts which records a user can access within a module — a branch manager can see only the transactions for their branch, not all branches. Implementing both levels adds complexity to the system design but is essential for businesses with sensitive data or multi-branch operations.

> **Admin accounts: the biggest security hole in most ERP systems**

> In almost every ERP system I've audited, there are more admin accounts than necessary, and those admin accounts are used for daily work. An admin account doing routine data entry can accidentally (or intentionally) modify system configuration, delete records, or bypass workflows. Best practice: every person has exactly one account with least-privilege permissions for their role. Admin accounts are separate, named accounts (not shared 'admin' logins) used only for system administration, with every session logged. The number of admin accounts should equal the number of people whose job requires admin access — which is usually 1–2 for a typical SME.

## Audit Trails: Security You Can Prove

Permissions control what users can do. Audit trails record what they actually did. A complete ERP audit trail captures: who performed the action (user ID and name), what action was performed (CREATE, UPDATE, DELETE), what was changed (before and after values for UPDATE actions), when it happened (timestamp with timezone), and from where (IP address, device). Audit trails are non-negotiable for financial data — they're required for tax audit defense, fraud investigation, and PDP Law compliance. Implement audit logging at the database level, not just the application level, so that direct database changes are also captured.

## Access Reviews: Keeping Permissions Current

Permissions designed at go-live will drift from reality. Staff change roles. Temporary access granted for a project never gets revoked. Former employees' accounts remain active. Quarterly access reviews — where every user's permissions are reviewed and certified by their manager — are the standard control. The review asks: is this user's role still correct for their current job? Do they still work here? Are there any permissions that look broader than their role requires? Act on the findings immediately — disable former employee accounts, correct wrong role assignments, and document the review as an audit control.

## RBAC in the Indonesian Regulatory Context

Indonesia's UU PDP (Undang-Undang Perlindungan Data Pribadi, No. 27 Tahun 2022) establishes requirements for how personal data is accessed and protected. For ERP systems containing employee personal data (name, address, NPWP, salary, bank account, health information for BPJS), access must be limited to those with a legitimate need, access must be logged, and data subjects have rights to know who has accessed their data. Your ERP's RBAC design needs to be documented and defensible to a data protection audit. This means: written role definitions, a permission matrix, quarterly access reviews, and audit logs retained for the legally required period.

## Sources & Further Reading

- IBM — Role-Based Access Control (RBAC) Implementation Guide — https://www.ibm.com/think/topics/role-based-access-control-implementation
- Cerbos — Role-Based Access Control Best Practices: 11 Top Tips — https://www.cerbos.dev/blog/role-based-access-control-best-practices
- BPK — UU No. 27 Tahun 2022 Undang-Undang Perlindungan Data Pribadi — https://peraturan.bpk.go.id/Details/234643/uu-no-27-tahun-2022

> **Key takeaway:** An ERP holds payroll, vendor contracts, bank details and full financial records, so a weak permissions design is a fraud risk, a breach risk and a compliance risk at once. Designing roles around job function rather than around individual people is what keeps the model coherent as staff change.

## Source links

- https://www.ibm.com/think/topics/role-based-access-control-implementation
- https://www.cerbos.dev/blog/role-based-access-control-best-practices
- https://peraturan.bpk.go.id/Details/229798/uu-no-27-tahun-2022

## FAQ

### What is the principle of least privilege and why does it matter for ERP design?

Least privilege means every user gets access only to the data and functions required for their job — nothing more. In ERP design this is foundational because the system holds payroll figures, vendor contracts, bank account details, and complete financial records. Getting it wrong creates compliance, fraud, and data-breach risk simultaneously.

### What is separation of duties and how is it enforced in an ERP system?

Separation of duties (SoD) ensures no single user can complete a financially significant transaction alone — for example, the person who enters a vendor invoice cannot also be the one who approves the payment. In ERP design, SoD rules are implemented as workflow constraints so the system itself prevents approval by the invoice creator. The post recommends building SoD into system design via a permission matrix rather than relying on a policy memo.

### Why is a permission matrix recommended before building the system, and what does it contain?

A permission matrix, created before development starts, maps every role (columns) against every system action (rows), with each cell marked Allow, Deny, or Conditional. Catching a separation-of-duties gap in a spreadsheet costs nothing, whereas finding it in a production system requires reworking workflows and retraining users. The matrix should be reviewed with the internal audit function before development begins.

### What is the difference between field-level and record-level security?

Module-level access controls whether a user can open a module at all. Field-level security restricts which fields within a record a user can see or edit — for instance, Finance Staff can see a vendor's name and invoice amount but not their bank account details. Record-level security restricts which records a user can access within a module, such as a branch manager seeing only their own branch's transactions.

### What does UU PDP (No. 27 Tahun 2022) require of ERP systems handling employee personal data?

Indonesia's UU PDP requires that access to personal data — including employee names, addresses, NPWP, salary, bank accounts, and BPJS health information — be limited to those with a legitimate need, that access be logged, and that data subjects have rights to know who accessed their data. ERP RBAC design must therefore be documented with written role definitions, a permission matrix, quarterly access reviews, and audit logs retained for the legally required period.

---

- HTML version: https://www.matthewswong.com/en/blog/erp-security-permissions-design/
- Bahasa Indonesia: https://www.matthewswong.com/id/blog/erp-security-permissions-design/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json