ERP security roles and access reviews

ERP access tends to grow in one direction. People get permissions added when they change jobs, cover for a colleague or hit an error at month-end, and almost nothing is ever taken away. After a few years a surprising number of users can create a vendor and pay it, or adjust inventory and approve the count. We use this checklist to put access back on a deliberate footing and keep it there.

It is written for any ERP. Screen and permission names differ between products, but the ideas are the same everywhere. It is about governance and internal control, the questions an auditor or a careful controller asks, not about testing or attacking a system.

The frameworks behind this list

You do not need to adopt a framework to use this page, but it helps to know the vocabulary your auditors use.

Source	What it covers
NIST SP 800-53 Rev. 5	A catalog of controls, grouped into families (listed below the table)
NIST role-based access control	The model of granting permissions to roles and roles to people, rather than permissions to people directly
AICPA SOC 2	Reports on a service organization's controls against the Trust Services Criteria. If your ERP is hosted, ask for the provider's SOC 2 report
COSO Internal Control: Integrated Framework (2013)	The internal control model most financial auditors use, with control activities as one of its five components

In NIST SP 800-53, the Access Control family includes AC-2 Account Management, AC-5 Separation of Duties and AC-6 Least Privilege. Audit and Accountability includes AU-2 Event Logging and AU-6 Audit Record Review, Analysis, and Reporting. Personnel Security includes PS-4 Personnel Termination and PS-5 Personnel Transfer. The Trust Services Criteria behind SOC 2 cover security, availability, processing integrity, confidentiality and privacy.

Design roles around jobs

Role-based access means permissions are granted to a role, and people are assigned roles. Done well, a new hire gets the right access in one step and a review asks "is this person still in this job?" rather than "should this person have these 400 permissions?"

• Start from job functions, not people. "AP clerk", "credit manager", "inside sales", "warehouse lead", "buyer". Name each role after the job rather than the first person who held it.
• Grant the least access the job needs. Read-only by default, with update, approve and delete only where the job requires it. This is the least privilege idea in NIST AC-6.
• Keep roles few and understandable. A few dozen roles that the business owners can read beats hundreds of near-duplicates nobody can explain.
• Avoid assigning permissions directly to users. Every direct grant is an exception that the next review has to find.
• Give each role a business owner. The owner of the AP process decides what the AP clerk role can do and signs its review.
• Write down what each role is for in one sentence, and which conflicting roles it must never be combined with.
• Separate administrator access from daily work. Administrators use a normal account for ordinary tasks and a separate privileged account for security and configuration changes.
• Include reports, dashboards and data exports in role design. Read access to costs, margins, pay rates and bank details is sensitive even when nobody can change them.

Segregation of duties conflicts in distribution

Segregation of duties means no single person can both carry out and conceal an error or a fraud. In a distributor, the classic conflicts sit where one person could create the thing that moves money or inventory and also approve or record the movement.

Conflict	Why it matters	Typical split
Vendor maintenance and AP payment	One person could add a vendor, or change a vendor bank account, and then pay it	Vendor setup and bank changes in purchasing or master data; payment runs in AP; bank changes confirmed by call-back to a known number
Customer credit and cash receipts	One person could extend credit or write off a balance, and apply or divert the cash that should have cleared it	Credit limits and write-offs with the credit manager; cash application with AR; write-offs above a limit approved by the controller
Inventory adjustment and counting	One person could count stock and then adjust the book to match, hiding shrinkage	Counters record; a supervisor or inventory control reviews and posts adjustments; large variances recounted
Pricing and order entry	One person could set a special price and then enter orders at it	Price and discount maintenance with a pricing owner; order entry with sales; overrides below a margin floor need approval
Purchasing and receiving	One person could order goods and confirm a receipt that never arrived	Buyers order; the warehouse receives; three-way match before payment
User administration and business roles	One person could grant themselves any of the above	Security administration held by someone with no finance or inventory posting role, with changes logged and reviewed

• List the conflicting pairs for your business using the table above as a start. Add any specific to your processes, such as rebates, consignment or returns.
• Map each conflict to the permissions that create it in your ERP. The conflict is between capabilities, not job titles.
• Check every user for conflicts, as well as every role. Conflicts usually come from a person holding two roles.
• Record and approve unavoidable conflicts. Small teams cannot always split duties. Where one person must hold both sides, write down why, who approved it and the compensating control.
• Define compensating controls for each approved conflict: a report of vendor bank changes reviewed weekly by someone else, a monthly review of inventory adjustments by value, a review of price overrides below margin.
• Test the conflict rules after every upgrade and role change. New releases add permissions that may land in existing roles.

Small teams

In a company with two people in accounting, perfect segregation is not possible. Add independent review instead. Someone independent looks at the risky changes (new vendors, bank changes, write-offs, large adjustments, price overrides) on a schedule and signs that they did.

Quarterly access reviews

A quarterly access review produces the evidence that your role design still holds.

• Produce a user access report from the ERP: every active account, its roles, any direct permissions, last login date and account type.
• Send each business owner the users in their roles. Managers confirm their own people, and role owners confirm what their role can do.
• Ask for a positive decision on every line: keep, change or remove. A blank reply is not an approval.
• Flag accounts with no login in 90 days for disable unless the owner explains them. Ninety days is a common rule of thumb. Pick a number and apply it consistently.
• Flag segregation of duties conflicts on the report, each with its approved exception or a removal.
• Make the changes and re-run the report to show they happened.
• Keep the signed review and the before and after reports where the auditors can find them.
• Review privileged and administrator accounts every quarter even if the rest of the review is less frequent.

Joiners, movers and leavers

Most access problems enter through the three moments a person's relationship with the company changes. NIST treats account management (AC-2), transfers (PS-5) and terminations (PS-4) as controls in their own right.

Joiners

• Access starts from an approved request naming the role, approved by the manager and, for sensitive roles, the role owner.
• Accounts are personal. One named user per person, created from the HR start record where possible.
• New accounts get roles, not copies of a colleague. "Make them like Pat" copies every exception Pat ever collected.

Movers

• A job change triggers an access change. HR or the manager notifies the ERP administrator when someone moves.
• Old roles are removed when new ones are added, after an agreed handover period at most.
• Temporary cover has an end date. Access granted for holiday cover or month-end help is removed on the date set when it was granted.

Leavers

• ERP access is disabled on the last day, or immediately for an involuntary departure, driven from the same HR event that ends network access.
• Disable before deleting. Keep the account disabled so history and audit trails still resolve to a name.
• Scheduled jobs, reports and integrations owned by the leaver are reassigned before the account is disabled, so nothing stops overnight without anyone noticing.
• A monthly check compares active ERP users with the HR list and investigates every account that has no current employee or contractor behind it.

Shared and service accounts

• No shared logins for people. A shared "warehouse" or "counter" account makes every audit trail useless. If a device must stay logged in, use per-person sign-in or a restricted account with a named owner and compensating review.
• Every service account has a named owner and a written purpose: which integration, which job, which system.
• Service accounts get only the permissions their integration needs. An integration that reads orders does not need to post journal entries.
• Service accounts cannot log in interactively where the ERP allows that restriction.
• Credentials are stored in a password vault, rotated on a schedule and when anyone who knew them leaves.
• Vendor and consultant access is time-limited, tied to a named person and disabled when the engagement ends.
• Built-in administrator accounts are controlled. Passwords held in the vault, use logged and day-to-day administration done with named accounts.

Audit logs

Logs are how you answer "who changed this, and when?" after the fact. They are also a control in their own right when someone reviews them.

• Turn on change logging for sensitive master data: vendor records and bank details, customer credit limits and terms, item costs and prices, plus user and role changes. Many ERPs log only what you switch on.
• Log security events: logins, failed logins, role and permission changes and new accounts.
• Protect the logs. People whose actions are logged should not be able to edit or delete the log, which is the idea behind NIST AU-9.
• Keep logs long enough for your audit cycle and any legal retention requirements. Confirm the period with your auditors.
• Review the high-risk logs on a schedule, with a named reviewer: vendor bank changes weekly, user and role changes monthly.
• Watch the cost of logging. Very broad logging can slow the ERP and fill the database. Log what you will review, and confirm with your vendor which logging is supported.

If your ERP is hosted

• Ask for the provider's SOC 2 report and read the exceptions and complementary user entity controls, the controls the provider expects you to run yourself.
• Confirm who can reach your data at the provider and how their access is approved and logged.
• Keep user access in your own hands. The provider runs the platform, but you still own who has which role in your company.

Next steps

If access has never been reviewed, do not start by redesigning every role. Run a user access report, disable leavers and dormant accounts and find the people who can both create vendors and pay them. Those three steps remove most of the risk in a week. Then design roles properly and put the quarterly review on the calendar.