Testing Who Can Do What in Your ERP. Check permitted tasks and actions that must be blocked.
Test ERP access by asking two questions together: can a person complete the work their role requires, and can they perform actions or combine powers the organization has not authorized? A role name or permission listing cannot answer either question on its own.
The useful unit of testing is a business scenario with a defined user, action, data scope, transaction state, and expected result. Include ordinary access, conflicting duties, support access, and temporary permissions. Verify what changes when those permissions are removed.
The security team should coordinate these tests in an authorized environment with appropriate test data. The objective is controlled validation of the organization’s access design, not an invitation to experiment against live systems or other users’ records.
Begin with the work a person is accountable for. “Purchasing user” is too broad. The role may need to create a requisition, change a draft order, view selected supplier information, or review a receipt. Each action has a different consequence.
For each action, identify the permitted population. A user may work only within a legal entity, site, department, customer group, or assigned case. Also identify the transaction states in which the action is allowed. Editing a draft may be acceptable while changing an approved record requires a different route.
Include viewing and extraction. A person who cannot edit a sensitive record may still be able to retrieve it through a report, export, attachment, search result, or connected application. The intended information boundary must cover the routes that actually exist in the implementation.
Have the business owner approve the required actions and scope. Have security and control specialists challenge the resulting permissions. Copying a long-standing user’s access can reproduce accumulated exceptions that nobody would approve today.
Use the following fields for each test row:
Pair positive and negative tests. If a buyer should change a draft order for Site A, test that legitimate action. Then test the corresponding restriction, such as changing an approved order without the required route or editing a record outside the authorized population.
A denied action should fail safely. The test should verify that the prohibited change did not occur, rather than relying only on an error message. For allowed actions, check that the user can complete the full workflow without needing an unnecessarily powerful role to resolve an ordinary handoff.
Separation of duties begins with the business consequence of combining powers. A generic list of role pairs is a starting point for discussion, not a substitute for examining the organization’s process.
Consider a hypothetical supplier-maintenance process. One person can change payment instructions. Another authorizes a payment batch. The control owner wants to prevent a single person from changing the destination and then independently authorizing the resulting payment.
The access review must examine the combined capability across the relevant systems and identities. It may matter whether a change requires separate approval, whether the approver can modify the same field, whether a delegated role adds authority, and whether a connected process executes under a more privileged identity.
Document the conflict as an outcome: which sequence of actions could produce the unacceptable result, over which population, and with what existing safeguards? Then determine which permissions or workflow decisions prevent it.
This hypothetical example does not establish a universal accounting or legal requirement. The responsible control owner must define the applicable duties, restrictions, and approved exceptions for the organization.
A role can look reasonable in isolation and become excessive when combined with other access. Build representative users with the combinations that will exist after go-live, including inherited groups, delegated responsibilities, and temporary assignments.
Review cross-system duties as well. A user may create a record in one application and approve a related event in another. The risk belongs to the end-to-end process even when each application’s local role review appears acceptable.
Include service and integration identities in a separate review. Record the business purpose, permitted actions, data scope, owner, and means of monitoring use. Confirm that an ordinary user cannot obtain broader powers merely by triggering an automated process unless that delegation is deliberately authorized and controlled.
Do not use a broadly privileged test account as evidence that an ordinary business role works. Test accounts should represent the intended access conditions, and their permissions should be verified before execution so unexpected results can be interpreted correctly.
For high-consequence actions, review the supported entry paths with the technical team. These may include the normal screen, a mobile interface, bulk import, a report action, an integration, or an application programming interface.
A hidden button alone is not adequate evidence that an action is unauthorized. The implementation needs to enforce the approved access rule where the request is processed. Authorized testing should verify the applicable routes without attempting unsanctioned intrusion or exposing real sensitive records.
Record differences in the test matrix. A user may be restricted correctly on the transaction screen but have broader access through a report or export. Similarly, a bulk process may use a different approval path. These are design questions to resolve, not reasons to assume every channel behaves identically.
For sensitive information, include what appears in error messages, notifications, downloaded files, and attachments. A workflow can enforce transaction permissions while still revealing information through its surrounding communication.
Small teams and unusual operating situations may make complete separation difficult. Where the organization permits an exception, document the specific conflict, affected population, reason, duration, and approving authority.
Describe any compensating control in operational terms. Who independently reviews what evidence, how do they establish completeness, when can they detect an issue, and what can they do about it? A manager’s signature is weak evidence if the reviewer cannot see the relevant changes or identify omitted transactions.
The qualified control owner should assess whether the alternative is acceptable. Some risks cannot be adequately addressed by an after-the-fact review, particularly when consequences become irreversible before detection.
Keep the exception connected to the access assignment. If the role changes or the business population expands, review whether the approval still applies. A historic exception should not silently authorize broader access.
Temporary access needs a beginning, a monitored period of use, and a verified end. Use this checklist for implementation, support, and emergency scenarios:
An expiry date in a request is not proof that access ended. Test the actual revocation behavior in the intended environment. The technical team should determine how sessions, cached permissions, group membership, and connected services affect the result.
Emergency access deserves a pre-agreed route that can be used under pressure. Define who may authorize it, the conditions for use, the evidence required, and the review afterward. “Emergency” should not become a permanent label for an ordinary support shortcut.
Test what happens when a user moves between jobs, covers an absent colleague, or joins a new rollout wave. The new role may be granted correctly while the old role remains active, creating a combination that was never reviewed.
Use a before-and-after access record. Verify removal of permissions that are no longer justified, addition of the approved new permissions, and continuity of legitimate work. Include records or workflows already assigned to the user so removal does not create unowned operational work.
For departing staff and retiring service identities, follow the organization’s approved security procedures. Coordinate account changes with ownership transfer, data retention, and active operational dependencies rather than leaving an unused identity active because nobody knows what relies on it.
Before release, summarize the access tests by business consequence. Identify material unauthorized capabilities, legitimate work that remains blocked, unresolved duty conflicts, and temporary access that has not been bounded.
Do not treat a high overall pass rate as sufficient when one unresolved path permits a consequential unauthorized action. Equally, access that is too restrictive can drive users toward shared accounts or uncontrolled workarounds. Both outcomes belong in the decision.
The release owner should receive named defects, evidence, accountable reviewers, and a clear recommendation for each material exception. Retest after corrections and preserve the tested role version.
A practical place to begin is one high-consequence business process. Write its allowed actions, identify the dangerous combinations, and test both sides with representative users. That produces a stronger access decision than approving a role catalogue that nobody has tried to use.