How should security teams design a view-only access model in ERP environments without giving users transactional rights?

A view-only model should grant read access to the forms and reports users need, while blocking create, update, post, or approval actions. The practical aim is to separate visibility from transaction capability, especially for executives and auditors. Teams should build the role from menu-item display permissions, then verify that no transactional privileges are inherited through related duties, roles, or references.

Why a view-only ERP model should separate visibility from transaction rights

A view-only ERP model should let people see what they need without inheriting the ability to change balances, post journal entries, approve transactions, or trigger downstream workflows. That distinction matters because ERP systems often blur display access, workflow authority, and data ownership. If those layers are not separated cleanly, read-only access can become a back door to operational action.

The design goal is not simply to deny obvious write buttons. It is to ensure the role exposes only safe inquiry functions, so users can inspect forms, drill into reports, and confirm values without acquiring capabilities that alter business records or financial state. In practice, that means treating menu visibility, form access, and transaction processing as distinct control points.

A useful starting point is to map the role around the questions users must answer, then strip away any action path that could create, update, post, reverse, approve, or export controlled data in a way that feeds another business process. In ERP environments, the safest read-only role is usually the one that is narrowly informative, not broadly interactive.

How to build the role without accidentally granting inherited privileges

In most ERP platforms, a view-only role should be assembled from display permissions first, then tested against the full privilege chain. That includes inherited duties, composite roles, reference privileges, workflow callbacks, and indirect access granted through shared menus or object-level permissions. A user may see only inquiry screens and still inherit transaction capability from a related role if the design is not checked end to end.

Role engineering should therefore start with the smallest workable menu set, then confirm that each entry is truly display-only at the object and action level. Where the platform supports separate rights for inquire, maintain, post, and approve, use those distinctions explicitly. When it does not, compensate by testing the effective permissions, not just the intended role design.

For practitioners, the hardest part is often not creating the role but proving that nothing else reintroduces write access. That is why access review quality matters as much as initial design. NHIMG’s IAM and IGA Basics is useful background for the broader authorization and governance model, and the Access Reviews and Certification Guide reinforces how to validate that the access you intended is the access actually assigned.

Which controls matter most when the goal is inquiry without action

Segregation of duties is the main guardrail in ERP view-only design, because the same person should not be able to both observe and execute a sensitive business process through separate role fragments. A clean read-only role must not collide with posting, approval, or master-data maintenance rights elsewhere in the access model. That is especially important in finance, procurement, inventory, and audit contexts, where a seemingly harmless inquiry path can sit next to a critical transaction path.

Role model quality also depends on the way the ERP platform handles authorization at the object level. Some systems distinguish between browse, display, and process actions; others rely heavily on menu path design and inherited duty structures. Security teams should know which layer actually enforces the restriction, then test the effective result rather than relying on the name of the role alone.

When the platform is complex, it helps to compare the role design against a formal authorization model, because “read-only” can mean different things across menus, objects, and workflows. NHIMG’s Authorisation Models Guide is a practical reference for understanding where role-based access is sufficient and where finer-grained controls are needed. For ERP teams, the point is to keep inquiry rights narrowly scoped and to prevent any path from collapsing into transactional authority.

Risk and Threat Considerations

View-only access becomes risky when the ERP role is treated as harmless and therefore exempt from privilege testing. In practice, inherited duties, shared menus, and poorly separated report functions can let a user move from “can see” to “can change” faster than the role owner expects. The same issue can create audit findings, control failures, and unauthorized business action even when the original intent was read-only access.

Failure mechanism: A role that is designed around display permissions can still acquire transactional ability through role inheritance, duty overlap, workflow permissions, or an adjacent object right that was not reviewed in the effective-access path.

Impact: Users who were supposed to observe only can post, approve, or alter ERP records, which undermines segregation of duties and can create financial, compliance, and fraud exposure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	View-only ERP roles depend on limiting effective permissions to inquiry only.
	AC-5 — Separation of Duties	ERP read-only design must prevent viewing from combining with posting or approval authority.
	IA-5 — Authenticator Management	ERP access models often rely on credentials and session controls that must not mask overbroad privilege.
Recommendation — Apply AC-6 to remove transaction rights from read-only ERP roles. Use AC-5 to separate inquiry access from transactional authority. Use IA-5 to manage credentials and prevent uncontrolled reuse of privileged access.
ISO/IEC 27001:2022	A.5.15 — Access control	ERP view-only access is an access-control design problem requiring restricted permissions.
	A.5.18 — Access rights	The question centers on granting and verifying the right level of ERP access.
Recommendation — Implement A.5.15 to restrict ERP access to read-only functions. Use A.5.18 to review and adjust ERP access rights so they remain view-only.
CIS Controls v8	CIS-6 — Access Control Management	Read-only ERP roles require controlling who can perform business actions.
Recommendation — Use CIS-6 to enforce least-privilege ERP access and remove transaction rights.

Practitioner Guidance

What to verify: Test the effective permissions, not the role description. Confirm that inquiry access does not include hidden maintain, post, approve, export-to-process, or reference actions through inherited roles or shared duties.

Common mistake: Security teams often stop after hiding buttons or menus. That is not enough if the backend authorization still permits the transaction, because a determined user or a downstream process can still invoke the capability.

Decision rule: If the role must support auditors or executives, prioritise broad visibility only where the underlying data is stable and the transaction surface is provably absent. If the business process is sensitive, constrain the role to the minimum inquiry path and recertify it regularly.

Practitioner takeaway: A good ERP view-only model is measured by the absence of effective transaction paths, not by the presence of a read-only label.