Define ERP permissions around actions and business scope: who may create, approve, amend, export or reverse a record, and for which entity, location or team. Test approval routing separately from ordinary editing rights. A hidden button is not sufficient evidence that an unauthorised action is prevented.
Let’s plan your ERP access controls.
Bring your workflow and the decisions you need to make. We’ll help you define the requirements, examine the trade-offs and plan a practical next step.
Write actions instead of broad role names
“Manager access” is ambiguous. A warehouse manager may approve a correction at one site but have no authority to change supplier bank details. Specify the resource, action and scope before designing a role.
Decide whether the initiator may also approve each sensitive action. Where separation is required, include replacement arrangements when an approver is unavailable. Temporary delegation needs a start, end and recorded scope.
OWASP's authorization guidance recommends least privilege, default denial and permission checks on every request. Use these principles to question implementation while keeping the approval policy specific to your organisation.
Build an approval matrix
| Action | Initiator | Approver | Scope and evidence |
|---|---|---|---|
| Create purchase request | Authorised requester | Purchase-policy owner | Entity and department |
| Amend approved order | Restricted editor | Reapproval where required | Changed values and reason |
| Adjust stock | Site operator | Designated controller | Warehouse and movement reference |
| Change supplier details | Master-data owner | Independently assigned role | Verified change record |
| Export customer records | Explicitly authorised user | According to policy | Population and access record |
| Reverse transaction | Restricted operator | Designated reviewer | Linked original and correction |
This illustrative matrix is not a complete security design. Replace its roles and conditions with your actual responsibilities.
Demonstrate the negative cases
Prove both that an authorised task succeeds and an unauthorised attempt fails. Try another entity's identifier, a session after access removal and a direct request to the underlying action. The engineering team should define and execute these technical tests safely.
Test approval at transaction commitment. Changing an approved amount or beneficiary should not retain approval intended for earlier values unless that behaviour is explicitly permitted by the business policy.
Background jobs, imports, mobile clients and integration credentials need controlled scopes too. Access must not depend only on the interface the user opened.
Plan access changes and emergency work
Document joiners, role changes and departures. Identify who reviews accumulated access and removes unused permissions. Shared accounts can make attribution difficult; define accountable access for routine and emergency work.
Emergency access needs a named purpose, limited scope, expiry and subsequent review. It should not become an undocumented permanent administrator role because launch was rushed.
Questions buyers ask
Should every change require approval?
No. Match controls to the consequence and operating context. Excessive routing can encourage workarounds. Agree which changes need independent review and which need attributable history only.
Does an audit trail prove security?
No. It helps investigate activity but does not replace prevention, access reviews or tested recovery. Decide who may view or alter the records themselves.
Prepare the acceptance exercise
Choose three roles, two scopes and a transaction whose approved values can change. Record expected allowed and refused outcomes. Include this matrix in the ERP vendor demonstration, then discuss implementation through ERP development.
