Role-Based Access and Segregation of Duties in ERP

Job titles are not an access-control specification

Giving everyone in finance the same ERP role is convenient until a junior invoice clerk can change supplier bank details or release a payment. A role should describe authorized duties and data scope, not simply reproduce the organization's job titles. The design needs to establish what a person may do, which records they may act on and which combinations of responsibilities create unacceptable risk.

This guide is for ERP process owners, security administrators and finance reviewers. Role-based access and segregation of duties support internal control, but assigning a role does not guarantee compliance or prevent every form of misuse. The business must identify sensitive actions and decide how preventive restrictions, independent review and monitoring work together.

Start with activities and the data they affect

List concrete actions such as creating a supplier, changing its bank account, recording a receipt, posting an invoice and releasing a payment. Distinguish read, create, edit, approve, post, reverse, export and administer. Access to an invoice screen should not automatically include approval or unrestricted export rights.

Add the relevant scope: company, department, warehouse, project or record ownership. A purchasing employee may need one legal entity's orders without seeing every entity's commercial terms. Do not assume that a hidden navigation item restricts the underlying API or report. Authorization needs enforcement at each supported server-side access path.

Evaluate combinations, not isolated roles

A user can acquire a conflicting combination through several individually reasonable assignments. Supplier maintenance plus payment release is a different risk from either duty alone. Review the effective permissions from all roles, group memberships and exceptional grants. Include service accounts and integrations, which can carry broad access outside ordinary employee reviews.

NIST SP 800-53 identifies separation of duties and least privilege as distinct access-control principles. Microsoft's finance-and-operations security guidance describes duties, privileges and role combinations in a concrete ERP implementation. Use these as references for the control discussion, then evaluate the actual product and business process rather than assuming terminology is identical everywhere.

Work through a supplier-payment scenario

In a hypothetical business, one person enters suppliers and another approves changes to payment details. An invoice clerk records the liability, and an authorized payment reviewer releases the payment. The process should prevent someone from introducing an unverified beneficiary and completing a payment without another accountable decision.

A small team may not have four separate people available. Identify the unavoidable overlap and an independent compensating review, such as a reviewer checking beneficiary changes against payment activity. Specify frequency, evidence and escalation. A documented exception is a risk decision with an owner and expiry; it is not a permanent exemption hidden in an administrator account.

Treat privileged and temporary access separately

Administrators need technical capabilities that ordinary business users should not receive. Use distinct named accounts where the architecture supports that separation, require the existing strong authentication controls and restrict the duration of elevated access. An emergency-access procedure should explain authorization, logging and post-use review before an emergency occurs.

Temporary project access also needs an end date. Consultants and support staff should lose access when their assigned work ends, while evidence of their approved actions remains available under the retention policy. Moving an employee to a different department should trigger review of old access, not only the addition of new roles.

Test denied actions as deliberately as permitted work

• Complete the employee's daily process using their intended role.
• Attempt a sensitive action that belongs to another role through the UI and API.
• Attempt access to another company or warehouse by changing a record identifier.
• Verify that exports and reports respect the approved data scope.
• Combine two roles and inspect the resulting permissions and conflicts.
• Remove a temporary grant and confirm the next request is denied as intended.
• Check that privileged actions create useful, access-controlled audit evidence.

Use realistic records and ordinary accounts. If every acceptance tester is an administrator, the project has not tested the production security model. Also verify the employee can complete required work; an overly restrictive design can drive staff toward shared logins and unapproved spreadsheets.

Keep the model maintainable after launch

Maintain a catalog with role purpose, approved duties, scope, owner and review date. Record why exceptions exist and when they expire. Review role changes after application updates because inherited privileges or new features can change effective access. Monitor sensitive activities selectively; indiscriminate logging can create cost and exposure without useful review.

Measure unresolved access requests, expired exceptions and recurring conflict patterns. Use those findings to improve the role design rather than granting broad rights to reduce a support queue. Begin with the supplier-to-payment journey and document its sensitive combinations. PRAESYNX enterprise software services and IT services provide routes to discuss application and identity requirements without replacing the organization's responsibility for access approval.