ERP Security: Roles, Duties and Audit Trails

An ERP system can create suppliers, approve purchases, pay invoices, adjust stock and post journal entries. That makes it the system where a security gap turns most directly into financial loss, whether through fraud, error or an attacker with stolen credentials. ERP security covers who can do what, how incompatible duties are kept apart, how changes are recorded, how integrations are controlled and how the system is kept patched and tested. This guide explains the controls that matter most, how to design roles and segregation of duties, how to protect data integrity and what to ask when choosing or reviewing an ERP partner, with a worked example of a conflict matrix.

Why ERP security is different

Most business systems hold information. An ERP also moves money and goods. The biggest risks are often not external hackers but legitimate users with too much access: one person able to create a supplier and approve payments to it, or to receive goods and adjust the stock records that would reveal a discrepancy. Strong ERP security therefore combines technical controls with business process controls.

Roles and least privilege

Design ERP roles around job functions and grant only the access each role needs:

• Start from processes, such as procure to pay, order to cash and record to report, and list the tasks in each
• Group tasks into roles for real job functions, such as purchasing clerk, accounts payable clerk and financial controller
• Separate view, create, approve and post permissions
• Restrict sensitive data, such as bank details, salaries and margins, to the roles that need it
• Avoid generic shared accounts and "super user" roles for daily work

Document each role with its purpose, tasks, data access and approval limits, and name a business owner who approves anyone being given it. Role design is easiest before go-live. Retrofitting least privilege onto a live ERP where everyone has broad access is slow and disruptive, so build it into the implementation plan.

Segregation of duties

Segregation of duties ensures no single person controls every step of a sensitive transaction. The NIST SP 800-53 security control catalogue includes separation of duties among its access controls, and auditors routinely test it in financial systems.

Typical conflicts to prevent include:

• Creating or editing a supplier and approving or releasing payments
• Raising a purchase order and approving it
• Receiving goods and approving the related invoice
• Posting journal entries and approving them
• Maintaining user access and performing financial transactions

Where a small team cannot separate every duty, use compensating controls: approvals by a second person, regular review of exception reports and independent reconciliation.

Protecting data integrity

• Enforce approval workflows for high-value or unusual transactions
• Lock closed accounting periods so past figures cannot change unnoticed
• Keep an audit trail of changes to master data, such as supplier bank details, prices and credit limits
• Alert on sensitive changes, such as a supplier's bank account being modified shortly before a payment run
• Validate data from integrations and imports before it posts
• Back up regularly and test restores

Changes to supplier bank details deserve special attention. Payment fraud often begins with a request to update bank details; requiring independent verification of any change, such as a call to a known contact, blocks much of it.

Authentication, integrations and infrastructure

Use single sign-on with multi-factor authentication, especially for finance and administrator roles. Give each integration its own credentials with narrow permissions; an integration that only creates sales orders should not be able to post journals. Store secrets securely and rotate them. For self-hosted or custom ERPs, apply security patches on a regular cycle, restrict network access to the ERP and its database, and encrypt data in transit and at rest. The OWASP Authorization Cheat Sheet is a useful reference when custom ERP code enforces permissions.

Worked example: a segregation of duties conflict matrix

Suppose a manufacturing company with a finance team of eight is implementing a custom ERP. It maps key tasks and marks the combinations no single role may hold:

TaskCreate supplierApprove POReceive goodsApprove invoiceRelease paymentPost journalCreate supplierConflictConflictConflictApprove POConflictConflictReceive goodsConflictConflictApprove invoiceConflictConflictConflictRelease paymentConflictConflictConflictPost journalConflict

It then designs roles that respect the matrix:

RoleTasks includedApproval limitsPurchasing clerkRaise purchase ordersNone; orders need approvalPurchasing managerApprove purchase ordersUp to an agreed value; above that, finance directorWarehouseReceive goodsNot applicableAccounts payable clerkEnter and match invoicesCannot approveFinancial controllerApprove invoices, post journalsJournals above a threshold need a second approverTreasuryRelease paymentsDual approval above a thresholdSupplier data administratorCreate and edit suppliersBank detail changes need independent verification

Because the finance team is small, the controller holds two duties that some companies would split. The company compensates with a monthly review of journals posted by the controller, carried out by the finance director. The ERP runs a nightly check that no user has been assigned roles combining any marked conflict, and reports exceptions to internal audit. The values and thresholds are the company's own choices.

Reviewing and testing ERP security

• Review user access quarterly with business owners, removing access no longer needed
• Run automated segregation of duties checks after every role change
• Review audit trails of sensitive changes monthly
• Test permissions after each release that touches roles or workflows
• Commission independent security testing for custom or internet-facing ERPs
• Rehearse the response to a suspected fraud or breach, including who freezes payments and who contacts the bank

Common mistakes

• Giving broad access at go-live "to avoid blocking anyone", then never tightening it
• Allowing supplier bank details to change without verification
• Using shared or generic accounts
• Over-privileged integration credentials
• Ignoring access for leavers and role changes
• Treating security as IT's job alone, without finance and audit involvement

An ERP consultant can help design roles and controls during selection and implementation; our guide to choosing an ERP consultant explains what to look for. Building security into rollout plans is covered in our guide to custom ERP implementation.

Frequently Asked Questions

What are the most important ERP security controls?

Least-privilege roles, segregation of duties, approval workflows, audit trails on master data, protected supplier bank details, multi-factor authentication, narrow integration credentials and regular access reviews.

What is segregation of duties in an ERP?

A control ensuring no single person can complete every step of a sensitive transaction, such as creating a supplier and approving payments to it.

How can small teams handle segregation of duties?

Separate the highest-risk duties and use compensating controls, such as second approvals, exception reports and independent reviews, where full separation is not possible.

How often should ERP access be reviewed?

Quarterly is common, with immediate changes when people change roles or leave, and automated conflict checks after every role change.

Secure your ERP with us

We design ERP roles, segregation of duties and audit controls into custom ERP systems from the start. See our custom app development services, or talk to us about your ERP.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.