ERP user roles and permissions best practices for safer work

An ERP becomes the operational backbone for finance, payroll, purchasing, inventory, manufacturing and reporting. Yet access often grows through shortcuts: a temporary privilege becomes permanent, a reporting role inherits write access, or a departing worker keeps an account. Those gaps turn ordinary platform power into business risk. Effective governance of ERP user roles and permissions begins by treating every entitlement as a decision that needs an owner, rationale and review date.

A sound model must also fit how Australian organisations work. A national team may connect people in Sydney, Melbourne, Brisbane, Perth and regional locations, with contractors and staff working from home or customer sites. Cloud accounting products such as Xero and MYOB often sit alongside Microsoft Dynamics, NetSuite or SAP. Access design therefore has to account for different locations, devices, employment types and regulatory obligations rather than assume a uniform office and permanent workforce.

Start with business processes, not job titles

Begin with the processes that create or change business data. Map who initiates a purchase, checks a claim, approves a supplier, reconciles a bank account, adjusts stock and releases a payment. Then separate the permission to perform each action from permission to view the underlying records. This reveals where a role genuinely needs access and where a broader administrative role would be an unsafe shortcut.

Job titles are weak building blocks. A “senior” employee in one unit may enter invoices, while another may only approve budgets; “finance” can mean anything from reporting to treasury. Build role families around tasks and responsibilities, then map people to them. Keep fine-grained entitlements available without creating hundreds of one-person roles, which are difficult to maintain and easy to overlook.

Document each role’s purpose, data scope, eligible approver and permitted actions. Include read, create, edit, delete, approve, export and administer as distinct rights where the ERP supports it. A permission request should state the process being performed rather than merely request “the same access as another person”. That evidence gives the approver enough context to reject unnecessary access without slowing legitimate work.

Apply least privilege and separation of duties

Least privilege means giving people enough access to do their assigned work and no more. Role-based access control is a practical starting point because it makes permissions repeatable and easier to audit. Where context matters, attribute-based rules can narrow a role: a cost-centre manager might see their own budget, while a national auditor sees approved records across entities. Combining roles and attributes avoids both over-broad access and unnecessary one-off accounts.

Segregation of duties protects organisations from error, misuse and fraud. In a procure-to-pay process, the person who raises a purchase should not also create the supplier, approve the invoice and reconcile the payment. Similar conflicts arise in payroll, where an employee record should not be changed and approved by the same person, or in treasury, where payment preparation and release need separate authority. Configure the ERP to detect incompatible rights and require a designated approver to resolve them.

Some work legitimately crosses those boundaries. Use documented exceptions with a named business owner, a risk assessment, compensating controls and an expiry date. For example, a small finance team may need a second person to release a low-value payment, but an exception should not grant unrestricted supplier creation or payroll editing. A temporary elevated entitlement should grant only the missing action, remain visible in the audit trail and disappear automatically when no longer required.

Match access to the sensitivity of data

Access decisions should reflect the sensitivity of the data, not only the screen used to work with it. Establish classifications for ordinary operational records, commercially confidential information, personal information, payroll data, banking details and material non-public information. Assign data owners who can decide who needs each class. This prevents a role designed for routine purchase approvals from receiving unrestricted visibility into employee or supplier files.

Field-level permissions are often more important than record-level ones. A purchasing officer may need a supplier’s address but not its bank details; a payroll user may need hours and leave balances but not tax-file numbers. Masking, restricted views and controlled disclosure can protect sensitive fields while preserving the task. Apply equivalent controls to attachments, comments, custom fields and workflow history, since sensitive data often appears outside the main form.

For organisations covered by the Privacy Act 1988, personal information must be handled in line with the Australian Privacy Principles. Depending on the entity and the incident, the Notifiable Data Breaches scheme may also require assessment and notification, so controlling who can export, copy or share records is part of the response. Health information may engage state and territory rules, such as the Victorian Health Records Act or relevant NSW and Queensland legislation. Legal and privacy owners should identify applicable obligations before roles are approved.

Control privileged, temporary and vendor access

Privileged access deserves separate treatment. System administrators, ERP configuration teams, database operators and integration developers can alter workflows, bypass approvals or expose bulk data. They should not use ordinary user accounts for support work. Where the platform permits, isolate these functions behind privileged access management, use separate administrator identities, require strong multi-factor authentication and log every sensitive configuration change. Emergency or “break glass” access should alert the appropriate security owner, time out automatically and trigger a prompt review.

Single sign-on and multifactor authentication simplify the control model when they are deployed well. Connect access to the corporate identity provider, apply conditional rules for device compliance and use phishing-resistant factors for high-risk users. Avoid relying on SMS alone where stronger options are available. Remove standing local administrator rights from day-to-day laptops, then elevate them only for a defined task, reducing both credential theft risk and the chance that a compromised account can make unauthorised changes.

External consultants and software vendors need only the access required for a support case. Prefer a named account tied to an approved ticket over a shared vendor login. Time-bound access, restricted modules, masked data and recording of the support session make activity attributable. Review vendor entitlements when contracts end, and remove credentials, API keys and integrations that are no longer active. Generic service accounts should have an owner, a documented purpose and no interactive login unless the architecture genuinely requires one.

Make account lifecycles predictable

Reliable access depends on a predictable joiner, mover and leaver process. The HR system should trigger provisioning when employment begins, changes, long-term leave or separation. The identity owner, manager and application owner then agree which roles apply, while system administrators implement the change against the effective date. Central request and approval workflows provide an audit trail and reduce dependence on email or direct messages, which are easy to misread or lose.

Termination is the most time-sensitive event. In Australian workplaces, final pay, accrued leave and superannuation can involve several systems and administrators, but those processes should never require continued ERP access after the employment relationship ends. Suspend the account immediately when the official separation is confirmed while preserving authorised records for payroll, tax, audit and legal obligations. Managers should also confirm whether employees still need access during notice periods or garden leave.

Internal moves need more than a new job title. A promotion can require removing sensitive rights even while adding others, and a temporary assignment can create an entitlement that should disappear on a known date. Use manager-approved, time-limited roles for acting appointments and system access from secondments. Run periodic reports for dormant, duplicate and orphaned accounts, tracing each one to an employee or service owner rather than deleting it without understanding its business use.

Test controls and learn from real activity

A permission model becomes trustworthy through recurring assurance. Schedule recertification based on risk: review high-impact and privileged rights frequently, while lower-risk operational roles can follow a broader cycle. The business owner should confirm both the need for continued access and whether the right level is still appropriate. Certification should cover inherited, group and manually added permissions, since these are often where unnoticed access survives. Keep evidence of the decision, including rejected or deferred requests.

Audit logs show whether controls work in practice. Capture who approved access, who used it, what changed, when it occurred and where the request originated. Centralise relevant logs so an administrator cannot quietly alter them, and restrict log access because logs can themselves contain personal and commercially sensitive information. Monitor patterns such as repeated access-denied events, unusual exports, repeated overrides and privileged changes outside change windows. Any alert should lead to a documented investigation rather than an assumption that unusual behaviour proves misconduct.

Use a small set of meaningful measures: time to approve and revoke access, orphaned accounts, overdue recertifications, segregation-of-duties conflicts, overdue vendor access and privileged actions without a ticket. Supplement them with staff training on approval requests, phishing and secure handling of ERP exports. The ASD Essential Eight provides a useful Australian reference for identity and privileged-access controls, while cloud-security standards such as ISO/IEC 27001 or Australian Signals Directorate guidance can support a broader framework. A mature ERP access model keeps authority scarce, traceable and proportional to the work.