What breaks when JD Edwards access is reviewed manually?

Why manual JD Edwards access review misses the real permission state

Manual review tends to collapse JD Edwards access into a list of roles or spreadsheet rows, but that is not the same as effective access. The system’s permission outcome can depend on how menus, actions, row security, and role sequencing combine at runtime. A reviewer who checks only the export sees structure, not the access path that actually exists.

This is why the problem is not just efficiency. The review can appear complete while still missing inherited or compounded access that changes what a user can truly do. In practice, the risk is a false sense of assurance: the evidence looks tidy, but the entitlement picture is incomplete.

That distinction matters most when access decisions are being justified to auditors or control owners, because the review artifact may describe assignments without proving behavior. For JD Edwards, the control question is less “what roles were listed?” and more “what effective permissions did those roles produce in combination?”

Where static exports fail as evidence

Static exports are weak evidence when the application applies security rules in layers. JD Edwards can make a permission appear absent at the role level while still granting it through another menu path, a row-security rule, or role sequencing. A spreadsheet cannot reliably model those interactions unless it reproduces the application’s own evaluation logic.

That gap creates a common audit failure mode: reviewers sign off on a narrow sample of roles, but the actual access space includes exceptions and combinations that were never enumerated. The result is incomplete segregation-of-duties analysis and weak confidence that privileged or sensitive functions are truly constrained.

Manual review also struggles when changes are frequent. Any export is already a snapshot, so the longer it takes to interpret, the more likely it is that the review is describing yesterday’s access rather than today’s. The more layered the security model, the more brittle the spreadsheet becomes as evidence.

What a reliable review has to prove instead

A reliable review has to prove effective access, not just assigned access. That means validating how the system resolves menus, actions, row rules, overrides, and role order into actual permissions, then using that result to test for SoD conflicts and excessive authority. Where possible, the review should show the effective permission path, not only the role name.

This is also where control owners need a clearer standard for completeness. If a reviewer cannot explain why a user can or cannot perform a sensitive action from the layered model itself, the review is not strong enough to support a clean audit conclusion. The evidence should let another practitioner reproduce the logic, not just trust the spreadsheet.

For broader control context, the review outcome maps naturally to CIS Controls v8, which emphasises account management and access control, and to NIST SP 800-53 Rev 5 Security and Privacy Controls, especially access control, identification and authentication, audit, and configuration management. For application-side verification, OWASP ASVS is the clearest external reference for checking that access control is actually enforced, not merely documented.

Practitioner Guidance

What to verify: Verify the effective access calculation against the JD Edwards security model, not against exported role names alone. If the review process cannot demonstrate menu, action, row, and sequencing effects, treat the evidence as incomplete.

Common mistake: Do not let “no privileged role in the export” stand in for “no privileged capability in the system.” The dangerous shortcut is assuming that one layer of security data is the control result.

What good looks like: The reviewer can trace a sensitive action from user to effective permission, explain any inherited access, and show how the review surfaced SoD conflicts or confirmed their absence.

Practitioner takeaway: In JD Edwards, manual review only works when it follows the application’s effective-access logic; anything less produces tidy evidence, but not trustworthy assurance.

Related resources from NHI Mgmt Group

• What breaks when access reviews rely on spreadsheets in JD Edwards?
• What breaks when shared-file access is reviewed only manually?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?