# How to Run an ERP User Access Review (Quarterly Checklist)

> Source: https://netray.co/erp-help/itm-erp-user-access-review-quarterly-checklist
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: ERP Help

## Short answer

An ERP user access review is a recurring control where system owners confirm that every active user, role and privileged permission is still justified. Extract users and roles from the ERP itself, join them to HR status, send each business owner a scoped list to certify or revoke, record the decisions, and execute the removals with ticket evidence.

## Kind

how-to

## System

it-leadership

## Erp

Any ERP (SAP, NetSuite, Infor, Dynamics, Epicor)

## Module

Security / User Access Reviews

## Query

how to do an ERP user access review

## Alternate Queries

- ERP user access review checklist for auditors
- quarterly user access review SOX ERP
- how to review ERP roles and segregation of duties
- terminated users still active in ERP audit finding

## Applies To

Any ERP with role-based security: SAP ECC and S/4HANA, Oracle NetSuite, Infor SyteLine and LN, Dynamics 365 and AX, Epicor Kinetic. Applies to SOX ITGC, ISO 27001 and customer security audits.

## Steps

### Quarterly access review procedure

**Items:**

Fix the scope: all production client or company, plus service accounts, integration users, API tokens and break-glass accounts. Test and sandbox tenants go in a lighter annual review.

Extract the population directly from the ERP, not from a spreadsheet someone maintained. SAP: SUIM user and role reports or tables USR02, AGR_USERS. NetSuite: Setup > Users/Roles > Manage Users with a saved search on role, last login and inactive flag. SyteLine: the Users and Authorizations forms plus the user tables in the application database.

Join the list to HR to find terminated, transferred and long-leave staff. Any active ERP account with no matching active employee or approved contractor record is a finding to fix first.

Add last-login data and flag accounts idle for 90 days or more. Dormant accounts are the most common audit exception and the easiest to remove.

Split the list by business owner (finance, purchasing, production, inventory, HR) and send each owner only their users and roles with a certify, modify or revoke choice.

Run a separate segregation of duties check on combinations such as create vendor plus approve payment, or create purchase order plus receive goods, and on any user holding admin or developer rights in production.

Execute every revoke or modify through your normal change ticket, then re-extract the list to prove the change took effect.

Archive the extract, owner responses, tickets and the final re-extract as one dated evidence pack.

## Sections

### What auditors actually test

**Body:**

External and internal auditors rarely care how elegant your process is. They test three things: that the population you reviewed was complete, that a named owner with authority made each decision, and that removals actually happened. If you cannot show where the user list came from, the review is treated as not performed.

Completeness is the weak point in most reviews. A report built from a manually maintained access matrix will miss accounts created directly in the ERP by an administrator. Always produce the population from a system report or query, record the date and the person who ran it, and keep the raw file unmodified alongside any annotated copy.

Timeliness matters as well. A review that closes two months after the extract can be challenged because users changed in between. Set a deadline of two to three weeks from extract to sign-off, and close the loop with a re-extract so the evidence shows the final state rather than an intention.

### Choosing reviewers and the review unit

**Body:**

Reviewing at the individual permission level overwhelms business owners. Review at the role level: each role has a documented description and a business owner, and the owner confirms who should hold it. Reserve line-by-line permission review for privileged roles such as system administrator, security administrator, financial period close and master data maintenance.

The IT manager should not certify business access for the business. IT certifies technical accounts, administrators and integration users; finance, operations and purchasing certify functional roles. Where one person is both owner and user of a role, route that line to their manager so nobody approves their own access.

Keep roles clean between cycles. Every review that ends with 'this role does everything in purchasing' is a sign the role design needs work. Track role count, users per role and the number of users with more than one high-risk role as simple trend metrics so you can show improvement quarter over quarter.

**Code:**

-- Generic idle-account pattern (adapt table and column names to your ERP)
SELECT user_id, full_name, last_login_date, role_count
FROM erp_users
WHERE is_active = 1
  AND (last_login_date IS NULL OR last_login_date < DATEADD(day, -90, GETDATE()))
ORDER BY last_login_date;

### Segregation of duties and privileged access

**Body:**

Segregation of duties is where reviews find real risk. Build a short conflict matrix with the combinations that matter to your business: vendor master maintenance with payment run, journal entry with journal approval, purchasing with goods receipt, price list maintenance with sales order entry, and inventory adjustment with cycle count approval. Check every user against it, not only the new ones.

Where a conflict is unavoidable in a small team, document a compensating control rather than ignoring it. Typical examples are a monthly review of all changes to vendor bank details by someone outside the process, or a report of manual inventory adjustments above a threshold reviewed by finance. Auditors accept a documented, evidenced compensating control; they do not accept silence.

Treat privileged and technical accounts separately. Developers with production write access, database administrators, shared service accounts and API integration users should have named owners, a stated purpose, password or token rotation evidence and logging. Shared logins that several people use are a standing finding; replace them with named accounts or vaulted, logged checkout.

### Joiner, mover and leaver controls between reviews

**Body:**

A quarterly review is a detective control. It works far better when preventive controls reduce what it finds. Tie account creation to an approved request that names the role, and tie termination to an HR event that triggers deprovisioning within a day. Most ERPs can lock rather than delete a user, which preserves the audit trail of who posted what.

Movers are the quiet problem. A buyer who moves to finance keeps buying rights unless someone removes them. Ask HR for a monthly transfer list and run it against the ERP user list, or make role removal a mandatory line in the transfer ticket.

Sample your own process monthly. Take five random leavers and confirm the ERP account was locked within your target window. If the sample fails, fix the trigger rather than waiting for the quarterly review to find it.

## Pitfalls

- Building the user list from an HR or IT spreadsheet instead of the ERP, which misses accounts created directly in the system.
- Letting managers click approve-all without reading, then having no evidence of any revoke decisions. Track revoke rate; a rate of zero for several cycles is suspicious.
- Reviewing only users and ignoring service accounts, integration tokens and API credentials, which often have the broadest access.
- Not re-extracting after removals, so the evidence shows a decision but not an outcome.
- Having the user's own manager certify administrator access without independent IT security oversight.
- Deleting terminated users instead of locking them, which breaks created-by and posted-by history in some ERPs.

## Ai Angle

An assistant such as ERPray, running read-only against the ERP's own user and role tables, can produce the idle-account list, the users with conflicting roles and the terminated-but-active comparison on demand, and show the query it ran so an auditor can reproduce it. It prepares the extract and the owner packets; the certify or revoke decision and the actual change stay with people and your ticketing process.

## Faq

### How often should we review ERP user access?

**Answer:** Quarterly is the common standard for financially significant ERPs under SOX-style controls, with privileged and administrator access reviewed more often, sometimes monthly. Smaller companies without formal audit obligations can run semi-annual reviews, but should still lock leaver accounts within a day or two of termination.

### Who should approve access in the review?

**Answer:** The business owner of each role or process, such as the finance controller for finance roles and the purchasing head for buying roles. IT approves technical and administrator accounts. No one should approve their own access, so route those lines to their manager or to a peer owner.

### What evidence do auditors want from an access review?

**Answer:** The system-generated user and role extract with date and author, owner responses showing certify or revoke per line, tickets proving the removals were executed, and a post-change re-extract. They also look for follow-up on exceptions and a record of who reviewed the review.

### What counts as a dormant account?

**Answer:** Most organisations use no login for 90 days as the threshold, with shorter limits for privileged users. Seasonal users such as year-end finance staff are the main exception, and should be disabled and re-enabled by request rather than left active all year.

## Search terms

ERP user access review, quarterly access review checklist, SOX ITGC user access review, ERP segregation of duties, terminated users active in ERP, ERP role review, dormant ERP accounts, ERP audit evidence user access, privileged access ERP, ERP joiner mover leaver

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json